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:29:13 +0200
- Subject: Re: Notes on a frame_unwind_address_in_block problem
- References: <20060706222157.GA1377@nevyn.them.org> <200608030511.46390.ak@suse.de> <20060803032136.GA7647@nevyn.them.org>
On Thursday 03 August 2006 05:21, Daniel Jacobowitz wrote:
> 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.
No, it will printk and SIGSEGV in this case. When x86-64 was done
a whole lot of old signal stuff was dropped as legacy.
> > > 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.
Yes, sorry for the confusion - you're right the vstubs only exist
for compat. I nearly added them at some point, but didn't because
there was really no advantage of keeping them in glibc.
With a vDSO this will be different.
> 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.
Which parts exactly of the signal frame does gas have trouble with?
-Andi