Re: Debugging of clones

[Daniel Berlin <dberlin at redhat dot com>]

Jason Merrill <jason@redhat.com> writes:

> >>>>> "Jason" == Jason Merrill <jason@redhat.com> writes:
> 
> > I'm thinking that then the debug info for the class would only mention the
> > abstract instance--the *INTERNAL* version, which is never actually emitted.
> > The info for the various specializations would only be emitted at file
> > (compilation unit) scope, like concrete instances are currently.
> 
> > As a result, the duplication in the class would go away from GDB's
> > perspective, though it would need to learn how to deal with multiple
> > concrete instances of an inline.
> 
> More thoughts: Currently, gdb relies on the DW_AT_MIPS_linkage_name crutch
> to find definitions of member functions.

No it doesn't. It just prefers them to the normal name, since it's
mangled.

dwarf2_linkage_name will return the linkage name if it exists,
DW_AT_name if it exists, or NULL, in that order.

The only other parts of dwarf2read that have DW_AT_MIPS_linkage_name
in them is one to transform attributes into string names (IE case
DW_AT_MIPS_linkage_name: return "DW_AT_MIPS_linkage_name"), and to do the same thing dwarf2_linkage_name does for partial dies.

It never does anything dependent on whether the linkage name exists or
not.


>  This won't work for finding
> multiple definitions, of course.  With my current patches, the only
> linkage_name attribute produced refers to the *INTERNAL* name, which
> doesn't help at all; a temporary solution might be to adjust things so that
> the DIE for the abstract instance claims to have the linkage name of the
> complete ctor, so that people could at least refer to one of the clones.
> 
> Daniel, what thoughts have you had about how to handle the clones?

Just don't give us the one marked *INTERNAL*, and we'll handle it.

What happens now is that it treats it like an overloaded function. If
you type "break foo::foo", it brints up a menu that says:

"[0] cancel
 [1] all
 [2] foo::foo at fred.c line 24
 [3] foo::foo at fred.c line 24
"

2 and 3 have different addresses. Choosing all pegs all the
constructors for you.

I'll be having it, for the moment, demangle them in verbose mode, so that it prints out
as

foo::foo[in-charge] at fred.c line 24
foo::foo[not in-charge] at fred.c line 24

Thus, letting you choose the right one.

We are discussing using foo::foo$Base as an easy way of specifying the
not in charge one directly, without having to go through the menu.

Already, foo::foo() will pick out the in-charge one by accident (it's
always output first, so we always find it first, since we add it to
the symtab first).
:)


> 
> BTW, what's the word on your patch to support FORM_ref_addr references
> between CUs?  Looking over the GDB ChangeLogs, it doesn't seem to have gone
> in yet.

It's awaiting approval, like a million other things.

--Dan