Re: Debugging of clones

[Daniel Berlin <dberlin at redhat dot com>]

Jason Merrill <jason@redhat.com> writes:

> >>>>> "Daniel" == Daniel Berlin <dberlin@redhat.com> writes:
> 
> > 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.
> 
> And things won't be confused if dwarf2_linkage_name doesn't return
> a valid symbol, i.e. it returns NULL or something like "operator="?

They shouldn't.


> 
> >> 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.
> 
> Hmm.  What do you think of my plan, then?  Again, I'm proposing to use the
> *INTERNAL* version for the abstract instance, and treat the others as
> concrete instances of it.  I think this makes the most logical sense.
> 
Yup. Sounds like it does.


> > What happens now is that it treats it like an overloaded function.
> >[...]
> 
> Sounds good.
> 
> Jason