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


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

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.

Jason


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