Re: [patch RFC] Re: Notes on a frame_unwind_address_in_block problem

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

> Date: Mon, 1 Jan 2007 14:19:27 -0500
> From: Daniel Jacobowitz <drow@false.org>
> 
> Now that the CFI issue in glibc is fixed, I'm back to this discussion
> from July.  Quoted below for reference, since it's been a while.
> 
> Here's a patch, that I'm looking for comments on.  It's not the most
> gorgeous code I've ever written, but it's the simplest solution I could
> come up with for a complicated problem.

Well, I really can't say I like it.  The problem is that it's been
several months since we last discussed this problem, so I'll have to
start to think again from scratch :(.  Isn't it just a matter of
making sure we set the right function address for signal trampolines?
That is, shouldn't we have a dwarf2_signal_frame_this_id() that
chooses a more sensible code address than frame_func_unwind()?

> It fixes eight failures in the x86-64 GNU/Linux testsuite and I
> believe it will fix those same failures for i386 also.  Test results
> for this platform are starting to look really good.  I hope I can
> get it to no failures during the next two weeks, and then move on to
> do the same for another platform.

Optimist!  We'll only have to wait for the GCC/glibc/kernel people to
come up with the next smart hack that they don't bother to test GDB
with and you'll have lots of failures to fix again ;-)

> Problem
> =======
> 
> The problem is a function which looks like this:
> 
>   <fde start> nop
>   function_label: code
>   <fde end> <function end>
> 
> Such functions are interesting to me because glibc and the Linux kernel
> both use them to provide unwind information for signal handlers.  The
> nop allows pc-1 to work, at least for libgcc's unwinder, even though
> function_label is pushed directly onto the stack as if it were a return
> address.
> 
> But GDB ends up subtracting one from the PC in some places it would be
> better not to.  We decide that get_frame_func for that frame should
> return the func associated with the fde start if the next frame is a
> normal frame, but the func associated with the function_label if the
> next frame is the sentinel frame.  This inconsistency breaks "finish"
> out of a signal handler, because the unwound frame ID when the command
> is issued doesn't match the current frame ID when we hit the temporary
> breakpoint.  We have several tests for this case.

But we have no stand-alone testcase.  You really need the right
version of glibc to be able to test this.  Could you come up with a
testcase that works everywhere, or at least on all targets?