On 7 February 2018 at 15:07, Manfred <mx2...@gmail.com> wrote: > > > On 02/07/2018 02:44 PM, Simon Marchi wrote: >> >> On 2018-02-07 02:21, Daniel Berlin wrote: >>> >>> As the person who, eons ago, wrote a bunch of the the GDB code for this >>> C++ >>> ABI support, and as someone who helped with DWARF support in both GDB and >>> GCC, let me try to propose a useful path forward (in the hopes that >>> someone >>> will say "that's horrible, do it this <clearly better way> instead") >>> >>> Here are the constraints i believe we are working with. >>> >>> 1. GDB should work with multiple DWARF producers and multiple C++ >>> compilers >>> implementing the C++ ABI >>> 2. There is no canonical demangled format for the C++ ABI >>> 3. There is no canoncial target demangler you can say everyone should use >>> (and even if there was, you don't want to avoid debugging working because >>> someone chose not to) >>> 4. You don't want to slow down GDB if you can avoid it >>> 5. Despite them all implementation the same ABI, it's still possible to >>> distinguish the producers by the producer/compiler in the dwarf info. >>> >>> Given all that: >>> >>> GDB has ABI hooks that tell it what to do for various C++ ABIs. This is >>> how >>> it knows to call the right demangler for gcc v3's abi vs gcc v2's abi. >>> and >>> handle various differences between them. >>> >>> See gdb/cp-abi.h >>> >>> The IMHO, obvious thing to do here is: Handle the resulting demangler >>> differences with 1 or more new C++ ABI hooks. >>> Or, introduce C++ debuginfo producer hooks that the C++ ABI hooks use if >>> folks want it to be separate. >>> >>> Once the producer is detected, fill in the hooks with a set of functions >>> that does the right thing. >>> >>> I imagine this would also clean up a bundle of hacks in various parts of >>> gdb trying to handle these differences anyway (which is where a lot of >>> the >>> multiple symbol lookups/etc that are often slow come from. >>> If we just detected and said "this is gcc 6, it behaves like this", we >>> wouldn't need to do that) >>> >>> In case you are worried, you will discover this is how a bunch of stuff >>> is >>> done and already contains a ball of hacks. >>> >>> Using hooks would be, IMHO, a significant improvement. >> >> >> Hi Daniel, >> >> Thanks for chiming in. >> >> This addresses the issue of how to do good software design in GDB to >> support different producers cleanly, but I think we have some issues even >> before that, like how to support g++ 7.3 and up. I'll try to summarize the >> issue quickly. It's now possible to end up with two templated classes with >> the same name that differ only by the signedness of their non-type template >> parameter. One is Foo<int N> and the other is Foo<unsigned int N> (the 10 >> is unsigned). Until 7.3, g++ would generate names like Foo<10> for the >> former and names like Foo<10u> for the later (in the DW_AT_name attribute of >> the classes' DIEs). Since 7.3, it produces Foo<10> for both. >> >> When GDB wants to know the run time type of an object, it fetches the >> pointer to its vtable, does a symbol lookup to get the linkage name and >> demangles it, which gives a string like "vtable for Foo<10>" or "vtable for >> Foo<10u>". It strips the "vtable for " and uses the remainder to do a type >> lookup. Since g++ 7.3, you can see that doing a type lookup for Foo<10> may >> find the wrong type, and doing a lookup for Foo<10u> won't find anything. >> >> So the problem here is how to uniquely identify those two classes when we >> are doing this run-time type finding operation (and probably in other cases >> too). >> >> Simon > > > Hi all, > > In the perspective of "type identity", the way I see it the issue has a few > parts: > > 1) How GCC compiles such templates > 2) How GCC emits debugging information via -g > 3) How such information is interpreted (and merged with the compiled code) > by GDB > > Regarding 1) and 2), IMHO I think that there should be a one-to-one > relationship between the compiled code output and debug info: > > This means that if GCC compiles such templates into two different > classes[1], it should generate two different type identifiers.
What do you mean by "such templates"? There have been several different examples in the thread, which should be handled differently. > Conversely, if it compiles the templates into the same class, then a single > identifier should be emitted for the single class compiled. > (This goes besides the point of what the standard dictates[2]) > > If I understand it right, currently the issue is that gcc emits two types > with the same debug identifier. > > Regarding 3), I think that after 1) and 2) are set up, GDB should be able to > find the correct type definition (using the most appropriate design choice). > > Hope this helps, Not really :-) You're basically just saying "GCC and GDB should do the right thing" which is a statement of the obvious. > [1] According to the findings of Simon, this appears to be the case with > clang, older GCC, and current GCC master. Do I understand this right? As I said above, it's not clear what you're referring to. > [2] About handling both templates instantiation as a single class, I think > that if GCC wants to emit a single class, then its argument type > instantiation should be well-definined,i.e. independent of the order of > declaration - see the findings from Simon earlier in this thread where you > could get the program output either -10 or 4294967286 depending on which > declaration would come first. That's just a GCC 7 bug in the handling of auto template parameters, see https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79092 It's not really relevant here, and is already fixed on trunk.
