Re: Notes on a frame_unwind_address_in_block problem

[Andi Kleen <ak@suse.de>]

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.

> 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.
 
> Alternatively, I could do this the long way: add an ELF vDSO in
> addition to the vsyscall pages, put syscall return trampolines there,
> have glibc use those if available.

I plan to add a vDSO myself.

> > We'll get a vDSO with kernel supplied unwind sectins sooner or later, but 
> > you'll have to handle the old vsyscall without unwinding anyways because 
> > it's not going to go away.
> > 
> > Also even the vDSO might end up without unwind information when compiled
> > with old compilers because I don't plan to support it without .cfi_*
> > support in binutils.
> 
> 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.

> 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.

-Andi