tmsriram added a comment. In D93747#2470189 <https://reviews.llvm.org/D93747#2470189>, @hoy wrote:
> 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. Yep, the demangler (which can be checked with c++filt) is very restricted on what comes after the "." It can be either numbers or characters but not a mix of the two. I guess we can enhance it. 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
