This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Debugging of clones
- To: Mark Mitchell <mark at codesourcery dot com>
- Subject: Re: Debugging of clones
- From: Jason Merrill <jason at redhat dot com>
- Date: 15 Feb 2001 16:15:40 +0000
- Cc: Daniel Berlin <dberlin at redhat dot com>, gcc at gcc dot gnu dot org, Jason Merrill <jason at redhat dot com>
- References: <u9pugkvxkf.fsf@casey.cambridge.redhat.com>
>>>>> "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