Re: [FYI] Inlining support, rough patch

Tom Tromey
2009-06-18T17:55:58Z

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