Again, please don't do this.
As you can see (see Tom Tromey's email), others have a use to go between
vtable types and the types they are attached to.
We should be getting away from linkage names, not going further towards
them.
There are a bunch of gdb bugs this won't solve, but adding an extensio
I've experimented with adding DW_AT_linkage_name for composite types in
LLVM. Here is impact on binary sizes (compiled with debuginfo):
Original size with DW_AT_linkage_name for composites
% increase
clang-7.01926574256 1952846192
1.4%
clang-tidy 12209
Ok, sounds reasonable. In case of debugger we are indeed "linking" RTTI
name with name in debuginfo.
I've checked LLVM docs, they generate Debuginfo from LLVM "Metadata", and
metadata for types already contains mangled names in "identifier" field:
https://llvm.org/docs/LangRef.html#dicompositetype
On Thu, Mar 1, 2018 at 3:26 PM, Andrew Pinski wrote:
> On Thu, Mar 1, 2018 at 12:18 PM, Roman Popov wrote:
>> Is there any progress on this problem?
>>
>> I'm not familiar with G++ , but I have little experience with LLVM. I can
>> try make LLVM emitting mangled names to DW_AT_name, instead of d
On Thu, Mar 1, 2018 at 12:18 PM, Roman Popov wrote:
> Is there any progress on this problem?
>
> I'm not familiar with G++ , but I have little experience with LLVM. I can
> try make LLVM emitting mangled names to DW_AT_name, instead of demangled
> ones.
> This way GDB can match DW_AT_name against
Is there any progress on this problem?
I'm not familiar with G++ , but I have little experience with LLVM. I can
try make LLVM emitting mangled names to DW_AT_name, instead of demangled
ones.
This way GDB can match DW_AT_name against RTTI. And for display it can
call abi::__cxa_demangle(name, NU
On Mon, Feb 5, 2018 at 6:06 AM, Simon Marchi wrote:
> Hi Martin,
>
> Thanks for the reply.
>
> On 2018-02-04 02:17 PM, Martin Sebor wrote:
>> Printing the suffix is unhelpful because it leads to unnecessary
>> differences in diagnostics (even in non-template contexts). For
>> templates with non-t
On 8 February 2018 at 14:05, Paul Smith wrote:
> Isn't the problem with the mangled name, which otherwise would be just
> what we wanted since it's easy to match and is unique in just the way
> we want it to be, that mangling is not standardized?
No, because mangling is standardized:
http://itaniu
On Thu, 2018-02-08 at 11:26 +, Michael Matz wrote:
> As I said upthread, the mangled name of a type (sans _Z prefix) is what is
> stored as the type name for RTTI purposes (i.e. std::type_info::name()).
>
> It's just that the debug info currently doesn't have any reference to that
> definite
Hi,
On Wed, 7 Feb 2018, Simon Marchi wrote:
> On 2018-02-07 12:30, Jonathan Wakely wrote:
> >> Ah ok, the class name appears mangled in other entities' mangled name. But
> >> from what I understand there's no mangled name for the class such that
> >>
> >> echo | c++filt
> >>
> >> outputs the
On 02/07/2018 12:11 PM, Daniel Berlin wrote:
Note that the ABI is explicitly designed so that type identity can be done
by address comparison.
correct, but be aware that lots of dynamic objects seem to step outside
the ABI by building shared objects with -Bsymbolic[1], or the equivalent
vis
> "Dan" == Daniel Berlin writes:
Dan> If there are multiple types named Foo<2u>, DWARF needs to be extended to
Dan> allow a pointer from the vtable debug info to the class type debug info
Dan> (unless they already added one).
This is what we did for Rust.
Rust doesn't have a stable ABI yet,
On 2018-02-07 12:30, Jonathan Wakely wrote:
Ah ok, the class name appears mangled in other entities' mangled name.
But
from what I understand there's no mangled name for the class such that
echo | c++filt
outputs the class name (e.g. "Foo<10>"). That wouldn't make sense,
since
there's n
On Wed, 7 Feb 2018, Simon Marchi wrote:
On 2018-02-07 12:08, Jonathan Wakely wrote:
Why would they not have a mangled name?
Interesting. What do they look like, and in what context do they appear?
Anywhere you need a name for linkage purposes, such as in a function
signature, or as a templ
On 7 February 2018 at 17:20, Simon Marchi wrote:
> On 2018-02-07 12:08, Jonathan Wakely wrote:
>>
>> Why would they not have a mangled name?
>>
>>> Interesting. What do they look like, and in what context do they appear?
>>
>>
>> Anywhere you need a name for linkage purposes, such as in a functio
On 2018-02-07 12:08, Jonathan Wakely wrote:
Why would they not have a mangled name?
Interesting. What do they look like, and in what context do they
appear?
Anywhere you need a name for linkage purposes, such as in a function
signature, or as a template argument of another type, or in the
st
On 2018-02-07 11:50, Jonathan Wakely wrote:
On 7 February 2018 at 16:36, Simon Marchi wrote:
On 2018-02-07 11:26, Michael Matz wrote:
Hi,
On Wed, 7 Feb 2018, Simon Marchi wrote:
This addresses the issue of how to do good software design in GDB to
support different producers cleanly, but I t
>
>
> 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 shoul
On 7 February 2018 at 17:03, Simon Marchi wrote:
> On 2018-02-07 11:50, Jonathan Wakely wrote:
>>
>> On 7 February 2018 at 16:36, Simon Marchi wrote:
>>>
>>> On 2018-02-07 11:26, Michael Matz wrote:
Hi,
On Wed, 7 Feb 2018, Simon Marchi wrote:
> This addresses the
On Wed, Feb 7, 2018 at 5:44 AM, 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 p
On 7 February 2018 at 16:36, Simon Marchi wrote:
> On 2018-02-07 11:26, Michael Matz wrote:
>>
>> Hi,
>>
>> On Wed, 7 Feb 2018, Simon Marchi wrote:
>>
>>> 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
>>
On 2018-02-07 11:26, Michael Matz wrote:
Hi,
On Wed, 7 Feb 2018, Simon Marchi wrote:
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
summ
Hi,
On Wed, 7 Feb 2018, Simon Marchi wrote:
> 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
On 2/7/2018 4:15 PM, Jonathan Wakely wrote:
On 7 February 2018 at 15:07, Manfred wrote:
On 02/07/2018 02:44 PM, Simon Marchi wrote:
[...]
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
befor
On 4 February 2018 at 05:01, Simon Marchi wrote:
> On 2018-02-03 13:35, Manfred wrote:
>> n4659 17.4 (Type equivalence) p1.3:
>>
>> Two template-ids refer to the same class, function, or variable if
>> ...
>> their corresponding non-type template arguments of integral or
>> enumeration type have id
On 7 February 2018 at 15:07, Manfred 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 bot
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
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,
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 instead")
Here are the constraint
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
Well, if ABI has specification for type naming, why not to put this name to
debug_info so debugger can use it?
In this case argument that "each producer has its own naming conventions"
no longer works. Any producer for given ABI must use ABI-specified names.
2018-02-05 12:12 GMT-08:00 Jonathan
On 5 February 2018 at 20:10, Roman Popov wrote:
> Do you mean that g++ guarantees uniqueness of mangled names for types? And
Of course. The mangled name is determined by the ABI and must be
stable, predictable and unique, so that linking works.
> uses name compare for operator== ?
Yes.
Do you mean that g++ guarantees uniqueness of mangled names for types? And
uses name compare for operator== ?
2018-02-05 12:08 GMT-08:00 Jonathan Wakely :
> On 5 February 2018 at 17:44, Roman Popov wrote:
> > Interestingly RTTI name also gives no guarantees:
> > http://en.cppreference.com/w/cpp/
On 5 February 2018 at 17:44, Roman Popov wrote:
> Interestingly RTTI name also gives no guarantees:
> http://en.cppreference.com/w/cpp/types/type_info/name
>
> << Returns an implementation defined null-terminated character string
> containing the name of the type. No guarantees are given; in partic
Interestingly RTTI name also gives no guarantees:
http://en.cppreference.com/w/cpp/types/type_info/name
<< Returns an implementation defined null-terminated character string
containing the name of the type. No guarantees are given; in particular,
the returned string can be identical for several ty
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
On 02/04/2018 10:06 PM, Simon Marchi wrote:
Hi Martin,
Thanks for the reply.
On 2018-02-04 02:17 PM, Martin Sebor wrote:
Printing the suffix is unhelpful because it leads to unnecessary
differences in diagnostics (even in non-template contexts). For
templates with non-type template parameters
On 4 February 2018 at 19:17, Martin Sebor wrote:
> I think this message would be the most meaningful if the "auto"
> part were replaced with the deduced type. With that, the suffix
> of the constant isn't important, just as in other contexts.
>
> I didn't consider the use of auto as a template par
On 5 February 2018 at 09:16, Stephan Bergmann wrote:
> On 05.02.2018 06:06, Simon Marchi wrote:
>>
>> On 2018-02-04 02:17 PM, Martin Sebor wrote:
>>>
>>> Printing the suffix is unhelpful because it leads to unnecessary
>>> differences in diagnostics (even in non-template contexts). For
>>> templat
On 05.02.2018 06:06, Simon Marchi wrote:
On 2018-02-04 02:17 PM, Martin Sebor wrote:
Printing the suffix is unhelpful because it leads to unnecessary
differences in diagnostics (even in non-template contexts). For
templates with non-type template parameters there is no difference
between, say A
Hi Martin,
Thanks for the reply.
On 2018-02-04 02:17 PM, Martin Sebor wrote:
> Printing the suffix is unhelpful because it leads to unnecessary
> differences in diagnostics (even in non-template contexts). For
> templates with non-type template parameters there is no difference
> between, say A<
On 02/03/2018 10:01 PM, Simon Marchi wrote:
On 2018-02-03 13:35, Manfred wrote:
n4659 17.4 (Type equivalence) p1.3:
Two template-ids refer to the same class, function, or variable if
...
their corresponding non-type template arguments of integral or
enumeration type have identical values
...
I
On 2/4/2018 6:01 AM, Simon Marchi wrote:
On 2018-02-03 13:35, Manfred wrote:
n4659 17.4 (Type equivalence) p1.3:
Two template-ids refer to the same class, function, or variable if
...
their corresponding non-type template arguments of integral or
enumeration type have identical values
...
It
On 2018-02-03 13:35, Manfred wrote:
> n4659 17.4 (Type equivalence) p1.3:
>
> Two template-ids refer to the same class, function, or variable if
> ...
> their corresponding non-type template arguments of integral or
> enumeration type have identical values
> ...
>
> It looks that for non-type tem
n4659 17.4 (Type equivalence) p1.3:
Two template-ids refer to the same class, function, or variable if
...
their corresponding non-type template arguments of integral or
enumeration type have identical values
...
It looks that for non-type template arguments the template type
equivalence is b
I've just checked g++8.0.1 from trunk, and the problem is still there. And
same with Clang compiler.
This is indeed is a serious issue for me, since my Python scripts for gdb
expect reliable dynamic type identification. However gdb is
completely powerless here. So I'm forced to stay on older compi
On Fri, 2018-02-02 at 23:54 -0500, Simon Marchi wrote:
> Your problem is probably linked to these issues, if you want to follow
> them:
>
> gcc: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81932
> gdb: https://sourceware.org/bugzilla/show_bug.cgi?id=22013
>
> As Carl said, it's a good idea to t
2018-02-02 20:54 GMT-08:00 Simon Marchi :
>
> GCC changed how it outputs unsigned template parameters in the debug info
> (from 2u to just 2), and it doesn't look like it's going to change it
> back. So I suppose we'll have to find a way to make GDB deal with it.
> Simon
>
I'm not so sure about
Yes, problem is still there in g++7.3 / gdb 8.1. I wonder why they decided
to emit different strings to RTTI and debug info? What is the technical
reason behind this?
-Roman
2018-02-02 20:54 GMT-08:00 Simon Marchi :
> On 2018-02-02 22:17, Roman Popov wrote:
>
>> Hello,
>> I'm trying to switch f
On 2018-02-02 22:17, Roman Popov wrote:
Hello,
I'm trying to switch from g++ 5.4 to g++ 7.2.
GDB 8.0.1 however does not understand RTTI generated by g++7.2, so my
Python scripts for GDB are not working.
Here is a code example:
struct base { virtual ~base(){} };
template< int IVAL, unsigned U
On Fri, Feb 2, 2018 at 7:17 PM, Roman Popov wrote:
> Hello,
> I'm trying to switch from g++ 5.4 to g++ 7.2.
> GDB 8.0.1 however does not understand RTTI generated by g++7.2, so my
> Python scripts for GDB are not working.
>
> Here is a code example:
>
> struct base { virtual ~base(){} };
>
> te
Hello,
I'm trying to switch from g++ 5.4 to g++ 7.2.
GDB 8.0.1 however does not understand RTTI generated by g++7.2, so my
Python scripts for GDB are not working.
Here is a code example:
struct base { virtual ~base(){} };
template< int IVAL, unsigned UVAL, unsigned long long ULLVAL>
struct der
52 matches
Mail list logo
