Re: [FYI] Inlining support, rough patch

[Tom Tromey <tromey@redhat.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