Re: Notes on a frame_unwind_address_in_block problem

[Andi Kleen <ak at suse dot de>]

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