* Re: dwarf2 and clones (was Re: What to do, what to do)
2001-05-13 15:41 ` dwarf2 and clones (was Re: What to do, what to do) Jason Merrill
@ 2001-05-13 16:10 ` Daniel Berlin
0 siblings, 0 replies; 2+ messages in thread
From: Daniel Berlin @ 2001-05-13 16:10 UTC (permalink / raw)
To: Jason Merrill; +Cc: gcc, gdb
On 14 May 2001, Jason Merrill wrote:
> >>>>> "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 can do this in the new dwarf2 reader, since I know the symbol list for
each die.
However, It would probably require changing the symbol processing order
around, so that we don't close off a list of pending symbols until the
very end, rather than as we pop back up (since we may later see symbols we
want to put in that scope).
Or at least, this seems to be the best thing to do.
> > > 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.
Correct.
I can completely get rid of it, if you like, bite the bullet, and generate
the qualified names
>
> > 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?
Three reasons.
One, for symbol completion, actually. Readline won't let us do what we
need to without more hooks right now (what we need to do is be able to get
a partial completion, and do more processing on the list afterwards, so
that we can lookup the lefthand side of the completion, to make sure it's
what we think it is, and add the rest of the symbols. IE if ti's a
filename, etc).
Two, the RTTI type info gives us the mangled name, and we need to go back
and match it against the demangled name when we try to lookup the type.
Since we don't have namespace support for dwarf2 right now (i'm aware it's
a 2.1 thing), we'll never have the symbols in the symbol tabl (they'll
never have the right prefix), and thus, RTTI will completely fail in the
presence of namespaces.
Also, this applies to the user interface as well, because the user will
expect symbols in different namesaces to have different prefixes.
Right now, if you have A::B::C, and D::B::C, and A and D are namespaces,
the reason we don't think we have two B::C's is because we prefer the
linkage name as the name, and thus, always have fully qualified names to
compare against. It never finds the right one until it searches the
demangled names, which were genrated from the real mangled name.
If you switched the preference, all of the sudden, GDB would think you had
two things called B::C, and get horribly confused trying to access them
(We rely on the ODR making this impossible, rather than try to handle
something that should never happen).
And because IIRC, the scope lookup is broken in the expression parser
for c, so it screws it royally sometimes.
I can fix the third reason, and if we make sure to include namespace
prefixes as part of the names of symbols in namespaces (or add dwarf2.1
namespace support), I can make DW_AT_mips_linkage_name as a
necessity completely disappear.
Fair enough?
See, while stabs really needs the mangled name, since it parses type
info from the name, dwarf2 doesn't. It's because it gives us the most
correct info right now, mainly because of namespaces.
> > Jason
>
^ permalink raw reply [flat|nested] 2+ messages in thread