This is the mail archive of the gdb@sources.redhat.com mailing list for the GDB project.


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

dwarf2 and clones (was Re: What to do, what to do)


>>>>> "Daniel" == Daniel Berlin <dan@cgsoftware.com> writes:

> So i'm fnishing up the new dwarf2 reader for gdb, and trying to get
> the clones to show up right.

> The problem is, how do we name them?

> See, each of the constructors, has at DW_AT_abstract_origin pointing
> to the same *out of the class DIE* subprogram die.
> That *out of the class* subprogram die has a DW_AT_specification
> pointing to the same *inside the class DIE* subprogram DIE for the
> constructor.
> That *inside the class DIE* has no DW_AT_MIPS_linkage_name on it, as
> one would expect, since we don't know exactly which of the two it
> really is, by mangled name.
> So for class fred, this *inside the class DIE* is named "fred".
> Since the neither the constructor dies, nor the *out of the class DIE*
> origin have names on them, we end up taking the name from the *inside
> the class DIE* subprogram DIE, which is simply "fred".

Yup.

> So we end up with two global functions named fred, which is not only
> wrong, but conflicts with the class name, which is very annoying..

They really shouldn't be bound to the name fred at global scope.  GDB
should recognise that we're in class scope and either bind it to a name
only within the class, or prefix fred:: to the internal name, or
something.

> I've hacked around this by checking the pubnames table to see if it
> has a name for the DIE's of the constructors, and using that in
> preference to trying to recursively find the attribute (in this case
> DW_AT_name or DW_AT_MIPS_linkage_name) in the abstract
> origins/specification.
> Because in the pubnames table, it says that the constructor DIES are
> really named fred::fred.
> Doing this for non-partial symbols requires special casing DW_AT_name
> and DW_AT_mips_linkage_name.

> All of this seems like a kludge just to get the right name.

> Can we just put a DW_AT_MIPS_linkage_name on the actual constructor
> dies (not the in-class one, the out-of-class ones), so we come up with
> the right name for them?

We could do that.  That would certainly be more correct than the current
situation.  However, I'd really like to move away from using
DW_AT_MIPS_linkage_name at all; it's not in the standard, and it uses a lot
of space.  My understanding is that we're only using it now because it was
easier to adapt the existing stabs code that way.

> Every other way seems like a serious pain in the ass (Trying to figure
> out the nesting level of the specification/origin die, and making up a
> name on the fly from where we think it is, etc).

It seems to me that there are several alternative ways to get the demangled
name:

1) Build up the decorated name from the debug info.
2) Use pubnames.
3) Use the mangled names from the symbol table.

What do we actually need the fully-qualified name for, anyway?  Won't the
name in the symbol table take care of most of those?

Jason


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