This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: gdb 8.x - g++ 7.x compatibility
- From: Daniel Berlin <dberlin at dberlin dot org>
- To: Roman Popov <ripopov at gmail dot com>
- Cc: Jason Merrill <jason at redhat dot com>, Andrew Pinski <pinskia at gmail dot com>, Richard Biener <richard dot guenther at gmail dot com>, Simon Marchi <simon dot marchi at polymtl dot ca>, Martin Sebor <msebor at gmail dot com>, Manfred <mx2927 at gmail dot com>, GDB Development <gdb at sourceware dot org>, GCC Development <gcc at gcc dot gnu dot org>
- Date: Sat, 3 Mar 2018 20:28:14 -0800
- Subject: Re: gdb 8.x - g++ 7.x compatibility
- Authentication-results: sourceware.org; auth=none
- References: <CAATAM3ED7B3wEJFmaZA_MaOtN5EGKSGFmusAf-Mg5hX35D2r6A@mail.gmail.com> <e9442bb24f681516f9726aee31e4c860@polymtl.ca> <1517667601.3405.123.camel@gnu.org> <CAATAM3H2V53F+v4mbAO5MpBbA1O3Qady3vFv6O0Rqj=moob4CA@mail.gmail.com> <c6352df2-6750-2c43-1ea1-3ddacffc1d95@gmail.com> <1b58e2df-5425-4f22-510c-d2e9f51040ba@polymtl.ca> <39845077-6bdf-f60d-9bfc-a491e7fa4fc7@gmail.com> <132fbd97-4f0d-020f-1c0f-1d4097800233@polymtl.ca> <CAFiYyc2LAjcFvhr2COzffv0Hs+zmNobzGrO6eBpBT6c1vnrQ-g@mail.gmail.com> <CAATAM3E4+w95LQ9rowFGDOTAoyDEV=M=p=ks2utohQm4SBpcJA@mail.gmail.com> <CA+=Sn1=CL2MAbZKY2GghEoBYmq+08GrJRERXEg8tXDJ5BKKTJQ@mail.gmail.com> <CADzB+2ngPYnY28_2ck24gbJxaSa=r_fOscEQCMUD+jeVMQoVtg@mail.gmail.com> <CAATAM3Etae8TQ2tynS2KeykN1xGYWcjJYnEThzoAoazA-TU7sA@mail.gmail.com>
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 extension
(like tom did for rust) to go between vtable types and concrete types will
solve *all* of them, be *much faster* than what gdb does now, and have
basically *no* space increase at all.
Meanwhile, i can hand you binaries where the size increase is in the
hundreds of megabytes to gigabytes for adding linkage names.
On Fri, Mar 2, 2018 at 3:06 PM, Roman Popov <ripopov@gmail.com> wrote:
> 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 . So it should not be
> hard to propagate it to object file.
>
> I will ask on LLVM maillist if they can emit it.
>
>
> 2018-03-01 13:03 GMT-08:00 Jason Merrill <jason@redhat.com>:
>
> > On Thu, Mar 1, 2018 at 3:26 PM, Andrew Pinski <pinskia@gmail.com> wrote:
> > > On Thu, Mar 1, 2018 at 12:18 PM, Roman Popov <ripopov@gmail.com>
> 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 RTTI. And for display it can
> > >> call abi::__cxa_demangle(name, NULL, NULL, &status), from #include
> > >> <cxxabi.h>.
> > >>
> > >> Will it work?
> > >
> > >
> > > 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 having the mangled symbol in DW_AT_name seems backwards and not the
> > > point of it.
> >
> > If we add the mangled name, which seems reasonable, it should be in
> > DW_AT_linkage_name.
> >
> > Jason
> >
>