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. On Mon, Feb 5, 2018 at 7:52 PM, Martin Sebor <mse...@gmail.com> wrote: > On 02/05/2018 09:59 AM, Simon Marchi wrote: > >> On 2018-02-05 11:45, Martin Sebor wrote: >> >>> Yes, with auto, the type of the constant does determine the type >>> of the specialization of the template in the source code. >>> >>> In non-type template arguments, and more to the point I was making, >>> in diagnostics, the suffix shouldn't or doesn't need to be what >>> distinguishes the type of the template, even with auto. The part >>> "with auto IVAL = 10" in the message >>> >>> 'void foo<IVAL>::print() [with auto IVAL = 10]': >>> >>> would be far clearer if auto were replaced by the deduced type, >>> say along these lines: >>> >>> 'void foo<IVAL>::print() [with int IVAL = 10]': >>> >>> rather than relying on the suffix alone to distinguish between >>> different specializations of the template. That seems far too >>> subtle to me. But I think the diagnostic format is (or should >>> be) independent of the debug info. >>> >> >> That makes sense. >> >> With respect to the suffix, I keep coming back to the reality >>> that even if GCC were to change to emit a format that GDB can >>> interpret easily and efficiently, there still are other >>> compilers that emit a different format. So the conclusion >>> that a general solution that handles more than just one format >>> (at least for non-type template arguments without auto) seems >>> unescapable. >>> >> >> If there are other compilers we wanted to support for which we can't >> trust the template format, we could always ignore the template part of >> DW_AT_name specifically for them. But since g++ and gdb are part of the >> same project and are expected to work well and efficiently together, I >> would have hoped that we could agree on a format so that gdb would not >> have to do the extra work when parsing a g++-generated file >> (consequently the same format that libiberty's demangler produces). >> >> Given the problem I illustrated in my previous mail, I don't have a >> general solution to the problem to propose. >> > > Okay, let me talk to Jason to see what he thinks. I'm open > to restoring the suffix for the debug info as long as it doesn't > adversely affect the diagnostics. I agree that if GCC can help > make GDB more efficient it's worth putting effort into. (I do > still think that GDB should work with other providers besides > GCC, even if perhaps not necessarily as efficiently.) > > Martin >
