This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [FYI] Inlining support, rough patch
- From: Tom Tromey <tromey at redhat dot com>
- To: Mark Kettenis <mark dot kettenis at xs4all dot nl>
- Cc: gdb-patches at sourceware dot org
- Date: Thu, 18 Jun 2009 11:55:42 -0600
- 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>
- Reply-to: tromey at redhat dot com
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.
Tom