On Thu, Mar 1, 2018 at 12:18 PM, Roman Popov <ripo...@gmail.com> wrote: > Is there any progress on this problem? > > I'm not familiar with G++ , but I have little experience with LLVM. I can > try make LLVM emitting mangled names to DW_AT_name, instead of demangled > ones. > This way GDB can match DW_AT_name against RTTI. And for display it can > call abi::__cxa_demangle(name, NULL, NULL, &status), from #include > <cxxabi.h>. > > Will it work?
Reading http://wiki.dwarfstd.org/index.php?title=Best_Practices: the DW_AT_name attribute should contain the name of the corresponding program object as it appears in the source code, without any qualifiers such as namespaces, containing classes, or modules (see Section 2.15). A consumer can easily reconstruct the fully-qualified name from the DIE hierarchy. In general, the value of DW_AT_name should be such that a fully-qualified name constructed from the DW_AT_name attributes of the object and its containing objects will uniquely represent that object in a form natural to the source language. So having the mangled symbol in DW_AT_name seems backwards and not the point of it. Thanks, Andrew > > Thanks, Roman > > > 2018-02-08 7:05 GMT-08:00 Richard Biener <richard.guent...@gmail.com>: > >> On Mon, Feb 5, 2018 at 6:06 AM, Simon Marchi <simon.mar...@polymtl.ca> >> wrote: >> > Hi Martin, >> > >> > Thanks for the reply. >> > >> > On 2018-02-04 02:17 PM, Martin Sebor wrote: >> >> Printing the suffix is unhelpful because it leads to unnecessary >> >> differences in diagnostics (even in non-template contexts). For >> >> templates with non-type template parameters there is no difference >> >> between, say A<1>, A<1U>, A<(unsigned) 1>, or even A<Green> when >> >> Green is an enumerator that evaluates to 1, so including the suffix >> >> serves no useful purpose. >> > >> > This is the part I don't understand. In Roman's example, spelling >> > foo<10> and foo<10u> resulted in two different instantiations of the >> > template, with different code. So that means it can make a difference, >> > can't it? >> > >> >> In the GCC test suite, it would tend to >> >> cause failures due to differences between the underlying type of >> >> common typedefs like size_t and ptrdiff_t. Avoiding these >> >> unnecessary differences was the main motivation for the change. >> >> Not necessarily just in the GCC test suite but in all setups that >> >> process GCC messages. >> > >> > Ok, I understand. >> > >> >> I didn't consider the use of auto as a template parameter but >> >> I don't think it changes anything. There, just like in other >> >> contexts, what's important is the deduced types and the values >> >> of constants, not the minute details of how they are spelled. >> > >> > Well, it seems like using decltype on a template constant value is >> > a way to make the type of constants important, in addition to their >> > value. I know the standard seems to say otherwise (what Manfred >> > quoted), but the reality seems different. I'm not a language expert >> > so I can't tell if this is a deficiency in the language or not. >> > >> >> That said, it wasn't my intention to make things difficult for >> >> the debugger. >> > >> > I hope so :). >> > >> >> But changing GCC back to include the suffix, >> >> even just in the debug info, isn't a solution. There are other >> >> compilers besides GCC that don't emit the suffixes, and there >> >> even are some that prepend a cast to the number, so if GDB is >> >> to be usable with all these kinds of producers it needs to be >> >> able to handle all of these forms. >> > >> > As I said earlier, there are probably ways to make GDB cope with it. >> > The only solution I saw (I'd like to hear about other ones) was to make >> > GDB ignore the template part in DW_AT_name and re-build it from the >> > DW_TAG_template_* DIEs in the format it expects. It can already do >> > that somewhat, because, as you said, some compilers don't emit >> > the template part in DW_AT_name. >> > >> > Doing so would cause major slowdowns in symbol reading, I've tried it >> > for the sake of experimentation/discussion. I have a patch available >> > on the "users/simark/template-suffix" branch in the binutils-gdb >> > repo [1]. It works for Roman's example, but running the GDB testsuite >> > shows that, of course, the devil is in the details. >> > >> > Consider something like this: >> > >> > template <int *P> >> > struct foo { virtual ~foo() {} }; >> > >> > int n; >> > >> > int main () >> > { >> > foo<&n> f; >> > } >> > >> > >> > The demangled name that GDB will be looking up is "foo<&n>". The >> > debug info about the template parameter only contains the resulting >> > address of n (the value of &n): >> > >> > <2><bf>: Abbrev Number: 11 (DW_TAG_template_value_param) >> > <c0> DW_AT_name : P >> > <c2> DW_AT_type : <0x1ac> >> > <c6> DW_AT_location : 10 byte block: 3 34 10 60 0 0 0 0 0 9f >> (DW_OP_addr: 601034; DW_OP_stack_value) >> > >> > I don't see how GDB could reconstruct the "&n" in the template, so >> > that's where my idea falls short. >> >> For other reasons I've always wanted sth like >> >> DW_OP_addr; DW_OP_name: n; DW_OP_stack_value >> >> thus put symbolical expressions in locations and have the consumer look >> them up >> (in context obviously). That way gdb can also choose to print foo<n> >> instead of >> foo<1> or foo<<optimized out>>. >> >> Of course that needs DWARF extensions. >> >> Richard. >> >> > Simon >> > >> > [1] https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git; >> a=shortlog;h=refs/heads/users/simark/template-suffix >>
