hoy added a comment.

In D93747#2470178 <https://reviews.llvm.org/D93747#2470178>, @tmsriram wrote:

> In D93747#2469556 <https://reviews.llvm.org/D93747#2469556>, @hoy wrote:
>
>>> In D93656 <https://reviews.llvm.org/D93656>, @dblaikie wrote:
>>> Though the C case is interesting - it means you'll end up with C functions 
>>> with the same DWARF 'name' but different linkage name. I don't know what 
>>> that'll do to DWARF consumers - I guess they'll probably be OK-ish with it, 
>>> as much as they are with C++ overloading. I think there are some cases of C 
>>> name mangling so it's probably supported/OK-ish with DWARF Consumers. 
>>> Wouldn't hurt for you to take a look/see what happens in that case with a 
>>> debugger like gdb/check other cases of C name mangling to see what DWARF 
>>> they end up creating (with both GCC and Clang).
>>
>> I did a quick experiment with C name managing with GCC and -flto. It turns 
>> out the `DW_AT_linkage_name` field of `DW_TAG_subprogram` is never set for C 
>> programs. If set, the gdb debugger will use that field to match the user 
>> input and set breakpoints. Therefore, giving `DW_AT_linkage_name` a 
>> uniquefied name prevents the debugger from setting a breakpoint based on 
>> source names unless the user specifies a decorated name.
>>
>> Hence, this approach sounds like a workaround for us when the profile 
>> quality matters more than debugging experience. I'm inclined to have it 
>> under a switch. What do you think?
>
> Just a thought, we could always check if rawLinkageName is set and only set 
> it when it is not null.  That seems safe without needing the option. Not a 
> strong opinion.

It seems that the demangler of the debugger is not able to handle an uniquefied 
name, even if the debug record originally comes with a linkage name.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D93747/new/

https://reviews.llvm.org/D93747

_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Reply via email to