This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


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

Re: Debugging of clones


>>>>> "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="?

>> 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.

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

Sounds good.

Jason


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