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

classic Classic list List threaded Threaded
27 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Re: [llvm-dev] Emiting linkage names for Types to Debuginfo (C++ RTTI support in GDB/LLDB)

Anastasia Stulova via cfe-dev


On Tue, Mar 6, 2018 at 9:36 AM Daniel Berlin <[hidden email]> wrote:
On Tue, Mar 6, 2018 at 9:28 AM, Daniel Berlin <[hidden email]> wrote:


On Tue, Mar 6, 2018 at 9:22 AM, David Blaikie <[hidden email]> wrote:


On Tue, Mar 6, 2018 at 8:39 AM Daniel Berlin <[hidden email]> wrote:
On Mon, Mar 5, 2018 at 11:55 PM, Roman Popov <[hidden email]> wrote:
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 :)

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.

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.
 

Fixing the parsing would fix the lookup issue in that case.
etc



_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: [llvm-dev] Emiting linkage names for Types to Debuginfo (C++ RTTI support in GDB/LLDB)

Anastasia Stulova via cfe-dev
In reply to this post by Anastasia Stulova via cfe-dev


On Tue, Mar 6, 2018 at 9:46 AM, David Blaikie <[hidden email]> wrote:


On Tue, Mar 6, 2018 at 9:28 AM Daniel Berlin <[hidden email]> wrote:
On Tue, Mar 6, 2018 at 9:22 AM, David Blaikie <[hidden email]> wrote:


On Tue, Mar 6, 2018 at 8:39 AM Daniel Berlin <[hidden email]> wrote:
On Mon, Mar 5, 2018 at 11:55 PM, Roman Popov <[hidden email]> wrote:
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 :)

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

_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: [llvm-dev] Emiting linkage names for Types to Debuginfo (C++ RTTI support in GDB/LLDB)

Anastasia Stulova via cfe-dev
In reply to this post by Anastasia Stulova via cfe-dev


On Tue, Mar 6, 2018 at 9:20 AM, Roman Popov <[hidden email]> wrote:
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 ;) 

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.




_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: [llvm-dev] Emiting linkage names for Types to Debuginfo (C++ RTTI support in GDB/LLDB)

Anastasia Stulova via cfe-dev
In reply to this post by Anastasia Stulova via cfe-dev


On Tue, Mar 6, 2018 at 9:48 AM, David Blaikie <[hidden email]> wrote:


On Tue, Mar 6, 2018 at 9:36 AM Daniel Berlin <[hidden email]> wrote:
On Tue, Mar 6, 2018 at 9:28 AM, Daniel Berlin <[hidden email]> wrote:


On Tue, Mar 6, 2018 at 9:22 AM, David Blaikie <[hidden email]> wrote:


On Tue, Mar 6, 2018 at 8:39 AM Daniel Berlin <[hidden email]> wrote:
On Mon, Mar 5, 2018 at 11:55 PM, Roman Popov <[hidden email]> wrote:
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 :)

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.

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.

Agreed.


_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: [llvm-dev] Emiting linkage names for Types to Debuginfo (C++ RTTI support in GDB/LLDB)

Anastasia Stulova via cfe-dev
In reply to this post by Anastasia Stulova via cfe-dev


On Tue, Mar 6, 2018 at 9:46 AM, David Blaikie <[hidden email]> wrote:


On Tue, Mar 6, 2018 at 9:28 AM Daniel Berlin <[hidden email]> wrote:
On Tue, Mar 6, 2018 at 9:22 AM, David Blaikie <[hidden email]> wrote:


On Tue, Mar 6, 2018 at 8:39 AM Daniel Berlin <[hidden email]> wrote:
On Mon, Mar 5, 2018 at 11:55 PM, Roman Popov <[hidden email]> wrote:
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 :)

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 :)
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.



_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: [llvm-dev] Emiting linkage names for Types to Debuginfo (C++ RTTI support in GDB/LLDB)

Anastasia Stulova via cfe-dev
In reply to this post by Anastasia Stulova via cfe-dev


On Tue, Mar 6, 2018 at 9:49 AM Daniel Berlin <[hidden email]> wrote:
On Tue, Mar 6, 2018 at 9:20 AM, Roman Popov <[hidden email]> wrote:
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 ;) 

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,

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

_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: [llvm-dev] Emiting linkage names for Types to Debuginfo (C++ RTTI support in GDB/LLDB)

Anastasia Stulova via cfe-dev
"
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.
 

2018-03-06 9:58 GMT-08:00 David Blaikie <[hidden email]>:


On Tue, Mar 6, 2018 at 9:49 AM Daniel Berlin <[hidden email]> wrote:
On Tue, Mar 6, 2018 at 9:20 AM, Roman Popov <[hidden email]> wrote:
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 ;) 

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,

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


_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
12