This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [FYI] Inlining support, rough patch
- From: Mark Kettenis <mark dot kettenis at xs4all dot nl>
- To: tromey at redhat dot com
- Cc: gdb-patches at sourceware dot org
- Date: Sat, 20 Jun 2009 11:56:40 +0200 (CEST)
- Subject: Re: [FYI] Inlining support, rough patch
- References: <20080613152754.GA4220@caradoc.them.org> <20080715192020.GB3094@caradoc.them.org> <200807172353.m6HNr1nY015884@brahms.sibelius.xs4all.nl> <20080718130308.GA19045@caradoc.them.org> <200807251446.m6PEkfwc027635@brahms.sibelius.xs4all.nl> <20080725174636.GB2433@caradoc.them.org> <m3y6umk447.fsf@fleche.redhat.com> <200903312042.n2VKgIUx003764@brahms.sibelius.xs4all.nl> <20090420154909.GA5386@caradoc.them.org> <200904222203.n3MM3Wo5001785@brahms.sibelius.xs4all.nl> <20090423124839.GA4556@caradoc.them.org> <m3skhxtoip.fsf@fleche.redhat.com>
> From: Tom Tromey <tromey@redhat.com>
> Date: Thu, 18 Jun 2009 11:55:42 -0600
>
> Ping.
>
> Mark> I firmly believe that if we want to add the capability to unwind
> Mark> through inlined functions, this fundamental principle should hold for
> Mark> inlined functions as well. This means that if we can detect that the
> Mark> current register state describes a process executing an inlined
> Mark> function we should faithfully reconstruct the register state for the
> Mark> call site of that inlined function. If I understand things correctly,
> Mark> the DW_TAG_inlined_subroutine tag provides information about the call
> Mark> site, which gives us the unwound program counter. But in order to
> Mark> reconstruct the complete register state, we need more information.
> Mark> The only viable source of that information is something like DWARF
> Mark> CFI; you don't stand a chance of doing a proper job here by doing
> Mark> instruction analysis.
>
> Daniel> DWARF CFI is not going to help with this; it only deals with 'real'
> Daniel> (i.e. not inlined) functions. There's no saved register state
> Daniel> from the virtual entry point. There isn't even an indicator
> Daniel> of where inlining occurs. Are you suggesting enhancing
> Daniel> the CFI information? I suspect the extra register state
> Daniel> would be generally unretrievable.
>
> It has been two months since this response. I think Daniel addressed
> your objections, at least to the extent they are addressable given the
> existing Dwarf specification.
>
> I would like it if this patch did not stay in limbo any longer. I
> think that goes for others, too: according to Joel's summit notes,
> this patch was explicitly asked about by attendees.
>
> At a minimum, could you answer his question above? Thanks.
Sorry, I have been travelling for the last month. I still think the
inline unwinder should not bend the rules we established for
unwinders. But since I'm obviously not capable of coming up with a
better way to do this, please use your own judgements about this diff.