Emiting linkage names for Types to Debuginfo (C++ RTTI support in GDB/LLDB)

Might be helpful to point to/include any details cited here for the purpose of this conversation - a bit hard for the rest of us to follow along.

The ambiguous names are probably incorrect - having two distinct types that have the same name’s not really going to work out well for a consumer. (so having the distinct types foo<11u> and foo<11> in source both produce a DWARF type named “foo<11>” I’d say is a bug that ought to be fixed - as is any other case where the names become ambiguous, otherwise matching up types between TUs would become impossible, which would be not good)

Sounds like Roman’s talking about other use cases apart from GDB.

Not sure I follow this - providing linkage names would provide a reliable mechanism to match the vtable symbol. There wouldn’t need to be any parsing, or any failure of parsing involved.

But, yes, addresses would be potentially a better description rather than having to match names in the object’s symbol table.

I don't understand how extra vtable ref DIE will help in case on
non-polymorphic classes. If you remove virtual destructor from example,
vtable won't be generated for class, but DWARF will still have incorrect
ambiguous names for types.

1. Calling them incorrect is ... not right. As Andrew quoted on the gdb
mailing list, this is what DWARF specifies should happen,

Might be helpful to point to/include any details cited here for the
purpose of this conversation - a bit hard for the rest of us to follow
along.

"
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 they are correct by spec. If you believe the spec is wrong, file an

issue on the DWARF web site and discuss it on the mailing list, and bring
back the consensus of the committee as to what to do :slight_smile:

The ambiguous names are probably incorrect - having two distinct types
that have the same name's not really going to work out well for a consumer.
(so having the distinct types foo<11u> and foo<11> in source both produce a
DWARF type named "foo<11>" I'd say is a bug that ought to be fixed - as is
any other case where the names become ambiguous, otherwise matching up
types between TUs would become impossible, which would be not good)

I'm sure the spec needs to be updated, i'm just saying "it's not wrong by
what the spec and best practices say to do right now".

2. The failure that was cited on the gdb mailing list only occurs on
polymorphic classes. If you have it occurring on non-polymorphic classes,
that seems like a very different problem, and probably related to the fact
that GDB does not know how to assemble or parse C++ names properly in some
cases. Otherwise, this would occur on literally every class you saw in
GDB, and that's definitely not the case:)

Sounds like Roman's talking about other use cases apart from GDB.

Yes.

The only reason linkage names would fix that issue is because they
provide an exact match to GDB's parsing failure.

Not sure I follow this - providing linkage names would provide a reliable
mechanism to match the vtable symbol. There wouldn't need to be any
parsing, or any failure of parsing involved.

But, yes, addresses would be potentially a better description rather than
having to match names in the object's symbol table.

I'm saying the only reason it would fix non-polymorphic classes is if gdb
is failing to parse names so that it can do die lookup properly.

GDB gives up in some cases and incorrectly says "lookup foo::bar::fred in
the global symbol namespace" instead of "lookup fred inside class bar
symbol namespace".

In those cases, the linkage name would fix it because it will appear in the
global symbol namespace.
But it would also work if you just fixed the name parsing.

If you want an example, gdb's parser understands that Foo<unsigned int> and
Foo<unsigned> are the same because it parses them properly.
It does not understand that Foo<2> and Foo<2u> are the same because it
parses them incorrectly.

Fixing the parsing would fix the lookup issue in that case.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81932
etc

Looks wrong to me. It doesn’t “uniquely represent” the object nor is it natural to the source language (foo<11> gets you the signed one, you’d have to write foo<11u> or foo<(unsigned)11> to get the unsigned one - yet Clang’s DWARF currently names them both foo<11>).

Can’t say I’m following this part… well, sort of following. But doesn’t seem relevant to Roman’s situation, which isn’t about GDB.

I think the only problem being addressed for GDB is the polymorphic case. The ability to match non-polymorphic types (with what, I’m not sure - not vtables in any case) is motivated by Roman’s other examples of IR, etc, not GDB’s dynamic type discovery.

  • Dave

Ah, but they aren’t necessarily the same type. Clang (& GCC?) are producing two different types but naming them both Foo<2>. That’s the ambiguity Roman’s referring to.

That’s a bug in Clang (& GCC?) that ought to be fixed.

I don't understand how extra vtable ref DIE will help in case on
non-polymorphic classes. If you remove virtual destructor from example,
vtable won't be generated for class, but DWARF will still have incorrect
ambiguous names for types.

1. Calling them incorrect is ... not right. As Andrew quoted on the
gdb mailing list, this is what DWARF specifies should happen,

Might be helpful to point to/include any details cited here for the
purpose of this conversation - a bit hard for the rest of us to follow
along.

"
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 they are correct by spec. If you believe the spec is wrong, file an

issue on the DWARF web site and discuss it on the mailing list, and bring
back the consensus of the committee as to what to do :slight_smile:

The ambiguous names are probably incorrect - having two distinct types
that have the same name's not really going to work out well for a consumer.
(so having the distinct types foo<11u> and foo<11> in source both produce a
DWARF type named "foo<11>" I'd say is a bug that ought to be fixed - as is
any other case where the names become ambiguous, otherwise matching up
types between TUs would become impossible, which would be not good)

I'm sure the spec needs to be updated, i'm just saying "it's not wrong by
what the spec and best practices say to do right now".

Looks wrong to me. It doesn't "uniquely represent" the object nor is it
natural to the source language (foo<11> gets you the signed one, you'd have
to write foo<11u> or foo<(unsigned)11> to get the unsigned one - yet
Clang's DWARF currently names them both foo<11>).

Yes, this is the gdb/gcc bug i cited, and ther eis probably a clang bug
somewhere too.

2. The failure that was cited on the gdb mailing list only occurs on
polymorphic classes. If you have it occurring on non-polymorphic classes,
that seems like a very different problem, and probably related to the fact
that GDB does not know how to assemble or parse C++ names properly in some
cases. Otherwise, this would occur on literally every class you saw in
GDB, and that's definitely not the case:)

Sounds like Roman's talking about other use cases apart from GDB.

Yes.

The only reason linkage names would fix that issue is because they
provide an exact match to GDB's parsing failure.

Not sure I follow this - providing linkage names would provide a
reliable mechanism to match the vtable symbol. There wouldn't need to be
any parsing, or any failure of parsing involved.

But, yes, addresses would be potentially a better description rather
than having to match names in the object's symbol table.

I'm saying the only reason it would fix non-polymorphic classes is if gdb
is failing to parse names so that it can do die lookup properly.

GDB gives up in some cases and incorrectly says "lookup foo::bar::fred in
the global symbol namespace" instead of "lookup fred inside class bar
symbol namespace".

In those cases, the linkage name would fix it because it will appear in
the global symbol namespace.
But it would also work if you just fixed the name parsing.

Can't say I'm following this part.. well, sort of following. But doesn't
seem relevant to Roman's situation, which isn't about GDB.

He did in fact claim non-polymorphic gdb lookup would fail (it won't), then
later talked about different use cases .
I'm just pointing out it will not.

I think the only problem being addressed for GDB is the polymorphic case.
The ability to match non-polymorphic types (with what, I'm not sure - not
vtables in any case) is motivated by Roman's other examples of IR, etc, not
GDB's dynamic type discovery.

Sure.
In those cases, there are a host of other problems

I wonder if abi::__cxa_demangle guarantees unambigous names?

No, it does not.

Interesting. Can you give an example of type where it fails?

I can't construct one out of thin air, but i believe someone cited one to
you on the gdb mailing list. It's entirely possible for the human readable
form of two symbols to be the same when the symbols are different.
I really just don't have the energy to copy the entire discussion on the
other mailing list here.

More to the point, the ABI literally does not guarantee it, and different
demanglers for the Itanium ABI (there are a bunch) do different things for
human readable names.
You cite below gcc vs gcc, which is different versions of the same
demangler. There are a bunch of Itanium C++ ABI implementations, including
demanglers and compilers, and i'd strongly caution you to remember that all
the world is not clang and GNU.

I'm currently working on hardware construction library for C++ (similar to
Chisel (which is written in Scala)). And since C++ has no standardized
reflection, I use DWARF as a source of reflection metadata. And in case of
G++ 6.3, which seem to emit same name names as abi::__cxa_demangle, it has
never failed so far in my case. And I have very diverse inputs.
In fact I was working on it for about a year, and I was thinking that it
how it supposed to work. Only after I upgraded to g++ 7 I've found out that
both modern g++ and clang do not emit unambiguous debuginfo.

This seems to be a different question than i thought you asked.
If you are asking "where will the demangled name between what
abi::__cxa_demangle and what GCC outputs in the debug info differ", it's
unlikely to differ if you use the same versions of both :wink:

But it will in some cases. Some bugs, some not.
Mangled names are not a panacea. I think you also wildly underestimate the
cost of demangling every symbol in a large binary, for example, which would
required for your suggestion, as well as the size of these symbols, etc.
It's enough that people wrote a fast demangler, for example. That's just
one issue.

As for the rest, you are taking a perspective that is pretty strongly
focused on your use cases, and currently, DWARF is pretty focused on the
other ones.
If you want to convince the committee/others that it should give up on the
part of the best practices i cited, go for it.

But you started by claiming this was necessary/important to fix the GDB
problems here, and it's simply not. In fact, it would not fix most of them
without a serious change in the way these things operate, and at high cost.
Suggesting to change gdb, gcc, clang, to fit your non-debugger use case is
taking a very big hammer and saying "it can also pound these nails".
While true, that doesn't mean you should.

I'd strongly suggest, if you have concerns about the ability of DWARF to
handle your use cases without linkage names, that you go to the DWARF
mailing list and start a discussion about, rather than just proposing a
solution.

In my experience, the people there have thought a lot about all of these
use cases, and you may in fact find a solution that doesn't require doing
anything at all.

Agreed.

I don't understand how extra vtable ref DIE will help in case on
non-polymorphic classes. If you remove virtual destructor from example,
vtable won't be generated for class, but DWARF will still have incorrect
ambiguous names for types.

1. Calling them incorrect is ... not right. As Andrew quoted on the
gdb mailing list, this is what DWARF specifies should happen,

Might be helpful to point to/include any details cited here for the
purpose of this conversation - a bit hard for the rest of us to follow
along.

"
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 they are correct by spec. If you believe the spec is wrong, file an

issue on the DWARF web site and discuss it on the mailing list, and bring
back the consensus of the committee as to what to do :slight_smile:

The ambiguous names are probably incorrect - having two distinct types
that have the same name's not really going to work out well for a consumer.
(so having the distinct types foo<11u> and foo<11> in source both produce a
DWARF type named "foo<11>" I'd say is a bug that ought to be fixed - as is
any other case where the names become ambiguous, otherwise matching up
types between TUs would become impossible, which would be not good)

I'm sure the spec needs to be updated, i'm just saying "it's not wrong by
what the spec and best practices say to do right now".

Looks wrong to me.

It doesn't "uniquely represent" the object nor is it natural to the source

language (foo<11> gets you the signed one, you'd have to write foo<11u> or
foo<(unsigned)11> to get the unsigned one - yet Clang's DWARF currently
names them both foo<11>).

Great, so fix clang/llvm to make it true :slight_smile:
That still doesn't involve adding linkage names to everything.
If we can't fix it, that's worth a discussion with the DWARF folks.

I think the only reason Roman’s discussing ways that would work without linkage names is because you pretty firmly said that adding linkage names was a bad idea (for the original issue of dynamic class identification).

Which, sure, it’s an idea with some issues - but the alternative (vtable DIEs with address/ref) isn’t without complications too - not to dismiss it, but to suggest having some real conversation about the tradeoffs seems worthwhile.

& while the vtable DIE solution addresses the dynamic class identification case, it doesn’t cover the other use cases Roman has in mind - other use cases that sound like they would be solved by having the linkage name of a type provided in the DWARF.

nod fair, might be worth it for the broader set of issues Roman seems to be dealing with (beyond the dynamic type identification issues that GDB demonstrates).

"
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."

And continuing the quote from same webpage:

“For template instantiations, the DW_AT_name attribute should contain both the source language name of the object and the template parameters that distinguish one instantiation from another. The resulting string should be in the natural form for the language, and should have a canonical representation (i.e., different producers should generate the same representation). For C++, the string should match that produced by the target platform’s canonical demangler; spaces should only be inserted where syntactically required by the compiler.”

As I said, for about a year I thought that this is how it supposed to work. Only after I upgraded compiler, I found all those issues.

that you go to the DWARF mailing list and start a discussion about, rather than just proposing a solution.
In my experience, the people there have thought a lot about all of these use cases, and you may in fact find a solution that doesn’t require doing anything at all.

nod fair, might be worth it for the broader set of issues Roman seems to be dealing with (beyond the dynamic type identification issues that GDB demonstrates).

I can ping DWARF maillist about using DWARF as a reflection mechanism. DWARF however is language-agnostic, and this seem to be C++ -specific issue.