This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
Re: Notes on a frame_unwind_address_in_block problem
- From: Andi Kleen <ak at suse dot de>
- To: Daniel Jacobowitz <drow at false dot org>
- Cc: Andreas Jaeger <aj at suse dot de>, Mark Kettenis <mark dot kettenis at xs4all dot nl>, gdb at sourceware dot org, libc-alpha at sourceware dot org
- Date: Thu, 3 Aug 2006 05:11:46 +0200
- Subject: Re: Notes on a frame_unwind_address_in_block problem
- References: <20060706222157.GA1377@nevyn.them.org> <200608030438.18827.ak@suse.de> <20060803024819.GA6543@nevyn.them.org>
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