Re: Notes on a frame_unwind_address_in_block problem

[Daniel Jacobowitz <drow@false.org>]

On Thu, Aug 03, 2006 at 05:11:46AM +0200, Andi Kleen wrote:
> On Thursday 03 August 2006 04:48, Daniel Jacobowitz wrote:
> 
> > Basically, right now x86_64 signal delivery always uses SA_RESTORER.
> 
> It will always. The kernel errors out if SA_RESTORER is not set.

I figured you'd do what i386 did - if SA_RESTORER isn't set, use a
trampoline in the vDSO.

> > Glibc provides the restorer.  It has some minimal, incorrect unwind
> > information.  If I remove the unwind information entirely from glibc,
> > GDB will know how to do the right thing through a signal handler - but
> > other unwinding scenarios like _Unwind_Backtrace won't.
> > 
> > I can add correct unwinding information but it would know about the
> > layout of rt_sigframe, and that's not always considered a public ABI.
> 
> in practice it is - lots of programs assume it. I guess it's the best
> you can do for now.

Good enough for me.  Andreas, in that case, is the patch in
http://sourceware.org/ml/gdb/2006-07/msg00131.html OK?

> > Fortunately I don't have to worry about this.  The vsyscall pages
> > aren't on the signal path 
> 
> The signal trampolines are in the vsyscall pages.
> 
> x86-64 doesn't actually have a gate page like i386.

I'm confused now.  x86-64 doesn't have signal trmapolines in its
vsyscall pages, unless they've been added in the last week or two.
The only vsyscalls on x86-64 are vgettimeofday and vtime, in the
git pull I've got here.

> > But, FYI, you can't actually write the unwind tables for these using
> > .cfi_* directives.  I tried.  I'd need at least three new directives
> > to do it sanely (for uleb128 escapes, sleb128 escapes, and adding the
> > "S" augmentation).  So I did it by hand, basically copied from the
> > i386 vDSO, but simpler since we don't need any pushes or pops.
> 
> If it's not possible to do sanely there won't be any unwind annotation.
> I refuse to deal with any more of this binary mess that the compat
> vsyscalls use because it's imho totally unmaintainable.

Not being able to annotate them correctly would suck.  Roland (I think)
did the hard work of describing them correctly; given the macros and
comments he used, I think it's pretty straightforward.

It would be possible to add the necessary bits to gas, but I wouldn't
hold my breath.

There was a third problem other than the two I mentioned above but
I'm afraid I can't remember what it was now.  I'd have to try it again.
I did work around both the uleb128 and sleb128 problems, and there's
actually a signal frame marker in sufficiently recent gas, but I
ran into another problem that made me give up.

-- 
Daniel Jacobowitz
CodeSourcery