Re: [FYI] Inlining support, rough patch

[Samuel Bronson <naesten at gmail dot com>]

At Sat, 20 Jun 2009 11:56:40 +0200 (CEST),
Mark Kettenis wrote:
> 
> > 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.

FWIW, there is no "register state for the call site" of an inlined
function. The inlined function's variables compete for stack slots and
registers with those of the calling function, and their code may be
interspersed and re-ordered. The closest thing to "register state for
the call site" that exists in this context is, well, the same register
state as that seen in the inline function.

This doesn't have anything to do with limitations of the debug
information, either; the compiler could not have such a concept as
"register state for the call site" without seriously compromising
the benefits of doing the inlining in the first place.

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