Re: Notes on a frame_unwind_address_in_block problem

[Daniel Jacobowitz <drow@false.org>]

On Thu, Jul 13, 2006 at 10:20:12PM +0200, Mark Kettenis wrote:
> > Date: Thu, 6 Jul 2006 18:21:57 -0400
> > From: Daniel Jacobowitz <drow@false.org>
> > II. 32-bit.
> > 
> > For 32-bit, though, it gets even more interesting.  Here's where $SUBJECT
> > comes into play.  I have a loaded vDSO (virtual shared object), which
> > exports __kernel_sigreturn.  This points at the first instruction of the
> > trampoline, i.e. one byte after the start of the dwarf2 FDE.  When I am
> > stopped in the signal handler, frame_unwind_address_in_block decides to
> > subtract one.  That points before the symbol, so the frame ID's function
> > ends up being NULL; there's no symbol covering that address.  Then when we
> > arrive at the signal trampoline during "finish", we no longer subtract one
> > - since we're at an executable instruction in the topmost frame - and thus
> > we do find the symbol.  The two frame IDs don't compare equal.
> 
> Ouch.  So in the end having the signal trampoline call the signal
> handler *is* a better design.

Um, I guess it depends what your goal is.  Given the rest of the system
architecture, for GNU/Linux, that'd waste a call instruction and some
code space; not much difference really.

> > Another solution would be to use the FDE start address as the code address
> > for dwarf2 signal frame IDs, instead of the function.  This would work on
> > the assumption that a single FDE would generally cover the entire trampoline
> > - a reasonable assumption, I think, and the consequences for the frame ID
> > changing while single-stepping are less disruptive here than the
> > alternative.
> > 
> > Mark, what do you think of that idea?  It seems to work.  It looks like the
> > patch at the end of this message.
> 
> In general, I think it's a bad idea to do this, but for the special
> case of a signal frame, especially in the presence of the 'S"
> augmentation, that might be a reasonable thing to do.  However, I
> think we can do better than that.  What about checking whether the
> address returned by frame_unwind_address_in_block() is equal to the
> FDE start address and add one bytes if that's the case before looking
> up the function corresponding to that address?

Unfortunately we can't readily; we'd have to add a bit of new code,
since all that's there is a call to frame_func_unwind (next_frame)
and that has no way to do the right thing.

I'd like to trigger off the signal augmentation.  If you'd prefer to
check the FDE start address, could you show me exactly what you have in
mind?

With that patch plus the fixed unwind information gdb.base/*.exp
results are basically clean for x86_64 - best I've ever seen them.
There is a corefile issue which I think is kernel related, and two
annotation tests fail because they don't account for a glibc with debug
information enabled.

-- 
Daniel Jacobowitz
CodeSourcery