Re: [FYI] Inlining support, rough patch

[Mark Kettenis <mark.kettenis@xs4all.nl>]

> Date: Tue, 15 Jul 2008 15:20:20 -0400
> From: Daniel Jacobowitz <drow@false.org>
> 
> I'm looking for any comments on the patch itself, test coverage on
> different systems (of both the patch and its included test cases), and
> for people to try it and tell me whether it works naturally or if any
> of my design choices seem wrong.  I don't know of any bugs in the GDB
> patch, although there are some limitations (see the new manual
> chapter).  Beware, though, it makes GDB more sensitive to incorrect
> debug info from GCC.

OK, I've looked a bit more at this diff, but I don't think I
completely understand it yet.  I really, really, don't like the way
you turn the frame unwinding completely upside down though.  Im afraid
that to me, thist suggests that your approach is seriously flawed.
Another indication is that you seem to need state for the inline
unwinder.

I can see why it would be desirable to have inlined functions appear
in a backtrace.  And I don't necessarily disagree with doing this
through inlined frames.  While they're not real stack frames, they're
not too different from frames we create for leaf calls that don't have
a stack frame of their own.  The important question is what the frame
ID for such a frame should be.  It seems you use the stack address and
entry point of the function in which the code was inlined.  As a
consequence you need to extend the frame ID to distinguish it from
that surrounding frame.  I think the correct thing to do is to use the
code address (low address or entry point) of the inlined function and
perhaps the stack pointer at that point to construct the frame ID.

I think this is doable if the inline unwinder is integrated with the
dwarf2 unwinder, or at least shares code with it.  That way the
generic frame unwinding code can stay much the way it is.  These
frames probably need to be marked and the unwinding code probably
needs a way to skip them.  But that will only have a fairly limited
impact.