This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: gdb 8.x - g++ 7.x compatibility


>
>
> This avoids the problem of the demangler gdb is using getting a different
> name than the producer used. It also should always give you the right one.
> If the producer calls the type "vtable fo Foo<2u>" here and "Foo<2>"
> elsewhere, yes, that's a bug. It should be consistent.
>
>
This should be Foo<2u> vs Foo<2>


> If there are multiple types named Foo<2u>, DWARF needs to be extended to
> allow a pointer from the vtable debug info to the class type debug info
> (unless they already added one).
> Then you would do *no* symbol lookups, you'd follow that pointer (gdb
> would add it to the symbol_info structure)
>

Note that the ABI is explicitly designed so that type identity can be done
by address comparison.

Also note that adding alternative names for symbols is probably a "not
great" idea, though it would work. The *vast* majority of debug info is in
those names, and adding long names will often triple or quadruple the size
of debug info.
Google has binaries where 90% of the size is in gigabytes of linkage
names.  People have worked hard to need the names *less*.

So you want to get *away* from going by name, especially when the compiler
knows "this is the vtable that goes with this type". It should just tell
you.
Right now, that is what you are missing "given a vtable for a type, how do
i get the type".

Trying to do that by name is a hack. A hack that has lasted 15+ years mind
you, but still a hack.

I would just kill that hack.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]