Re: Notes on a frame_unwind_address_in_block problem

[Daniel Jacobowitz <drow@false.org>]

On Thu, Aug 03, 2006 at 04:38:18AM +0200, Andi Kleen wrote:
> On Thursday 03 August 2006 04:04, Daniel Jacobowitz wrote:
> > On Tue, Jul 18, 2006 at 02:35:20PM -0400, Daniel Jacobowitz wrote:
> > > The only caveat is that it is in glibc, but knows about the kernel
> > > layout of struct rt_sigframe - specifically that a struct ucontext
> > > lives just above the SA_RESTORER return address.  Andi, what do you
> > > think of that?  If it's a bad idea, we may need a different approach
> > > (i.e. a vdso).
> 
> Missing context a bit. What exactly is the problem?

Here's some context:
  http://sourceware.org/ml/gdb/2006-07/msg00131.html

Basically, right now x86_64 signal delivery always uses SA_RESTORER.
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.

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.

But I don't want to do either of those without checking with you;
one is an ABI issue, the other is a huge amount more work than I was
planning to do to fix the bug.

> 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 and if you use an old compiler to build
your kernel, this will just break.  Considering how long it's already
been broken...

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.

-- 
Daniel Jacobowitz
CodeSourcery