Re: [FYI] Inlining support, rough patch

[Mark Kettenis <mark dot kettenis at xs4all dot nl>]

> Date: Mon, 20 Apr 2009 11:49:09 -0400
> From: Daniel Jacobowitz <drow@false.org>
> 
> On Tue, Mar 31, 2009 at 10:42:18PM +0200, Mark Kettenis wrote:
> > I agree that it is an important feature.  I'll see if I can wrap my
> > head around this again now that I'm not in an airport every other
> > week again.
> 
> Hi Mark,
> 
> Did you have a chance to look at this?  If not, maybe we can find a
> third party to review the patch?  If someone volunteers, I'll refresh
> the diffs from our internal tree.  Nothing algorithmic has changed,
> but we have a few bug fixes and improved testcases.

Yes, I did spent some of my time looking at the diff again, and
thinking about the proper solution for the problem at hand.  And I'm
afraid that it has reinforced my initial opinion about your approach.
Let me explain.

The fundamental principle behind unwinding the stack is, given the
register state of a process/thread executing code in a certain
function, figuring out the register state at the point where this
function was called.  This register state may be incomplete because
information that is no longer necessary for the program to continue
past this point has been lost.  However we assume that at least the
stack pointer and program counter can be recovered (if not we
terminate the unwinding).

I firmly believe that if we want to add the capability to unwind
through inlined functions, this fundamental principle should hold for
inlined functions as well.  This means that if we can detect that the
current register state describes a process executing an inlined
function we should faithfully reconstruct the register state for the
call site of that inlined function.  If I understand things correctly,
the DW_TAG_inlined_subroutine tag provides information about the call
site, which gives us the unwound program counter.  But in order to
reconstruct the complete register state, we need more information.
The only viable source of that information is something like DWARF
CFI; you don't stand a chance of doing a proper job here by doing
instruction analysis.

That is why I still think integrating inline support in the DWARF
unwinder is the right way forward.  I really think that unwinding
further down the stack to get information for an inlined frame like
you do in your diff is wrong, and I feel like you're digging a fairly
deep hole for yourself here.

That said, the proper response from me would be to hack up something
closer to what the right solution would be.  But I'm afraid I simply
don't have the motivation to do such a thing anymore.  The environment
in which GDB is being developed seems to have changed.  It feels like
I'm the only one who is still hacking on code for fun, and that I'm
being surrounded by people for which writing GDB code is their job.
It sometimes feels like most of the effort goes into supporting
debugging embedded targets hosted on non-free operating systems.  And
I increasingly find myself fighting against proposals to change
development practices (C++, XML) and a mentality to fix bugs by
slapping more code into GDB instead of taking some time and exploring
alternative solutions.  Perhaps the time has come for me to simply
give up.

Mark