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: Daniel Jacobowitz <drow at false dot org>
- To: Andi Kleen <ak at suse dot de>
- 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: Wed, 2 Aug 2006 23:21:36 -0400
- 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> <200608030511.46390.ak@suse.de>
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