All of lore.kernel.org
 help / color / mirror / Atom feed
* sigreturn on sparc64
@ 2006-05-24 18:00 H. Peter Anvin
  2006-05-24 21:21 ` David Miller
                   ` (3 more replies)
  0 siblings, 4 replies; 5+ messages in thread
From: H. Peter Anvin @ 2006-05-24 18:00 UTC (permalink / raw)
  To: sparclinux

I'm having an issue with klibc on sparc64 (i.e. a 64-bit userspace
binary), which doesn't appear on sparc32:

If I leave the signal restorer function as NULL, I get a SIGSEGV on
attempting to return from the signal handler.

If I generate a system call stub for rt_sigreturn, and pass that in as
the restorer, then the process will loop forever on signal handler
return.

A lot of architectures have ugly corners in this area (i386, for
example, needs to drop one word from the stack before calling the
sigreturn system call.)  However, I simply don't understand the SPARC
architecture well enough to understand if/what I'm supposed to do
here, or if this is simply a bug.

	-hpa


^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: sigreturn on sparc64
  2006-05-24 18:00 sigreturn on sparc64 H. Peter Anvin
@ 2006-05-24 21:21 ` David Miller
  2006-05-24 21:23 ` H. Peter Anvin
                   ` (2 subsequent siblings)
  3 siblings, 0 replies; 5+ messages in thread
From: David Miller @ 2006-05-24 21:21 UTC (permalink / raw)
  To: sparclinux

From: "H. Peter Anvin" <hpa@zytor.com>
Date: Wed, 24 May 2006 11:00:59 -0700 (PDT)

> I'm having an issue with klibc on sparc64 (i.e. a 64-bit userspace
> binary), which doesn't appear on sparc32:
> 
> If I leave the signal restorer function as NULL, I get a SIGSEGV on
> attempting to return from the signal handler.
> 
> If I generate a system call stub for rt_sigreturn, and pass that in as
> the restorer, then the process will loop forever on signal handler
> return.
> 
> A lot of architectures have ugly corners in this area (i386, for
> example, needs to drop one word from the stack before calling the
> sigreturn system call.)  However, I simply don't understand the SPARC
> architecture well enough to understand if/what I'm supposed to do
> here, or if this is simply a bug.

GLIBC is the source of all knowledge :-)

libc/sysdeps/unix/sysv/linux/sparc/sparc64/sigaction.c

In there you'll see that you have to set the sa_restorer
to NULL and pass in the "stub" address minus 8, as the
4th argument to rt_sigation system call.

The "stub" is simply:

stub:
	mov	__NR_rt_sigreturn
	ta	0x6d

on sparc64.  So:

	sys_rt_sigation(signr, &action, &old_action, &stub - 0x8, _NSIG/8);

Hope this helps.

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: sigreturn on sparc64
  2006-05-24 18:00 sigreturn on sparc64 H. Peter Anvin
  2006-05-24 21:21 ` David Miller
@ 2006-05-24 21:23 ` H. Peter Anvin
  2006-05-24 21:34 ` David Miller
  2006-05-24 22:02 ` H. Peter Anvin
  3 siblings, 0 replies; 5+ messages in thread
From: H. Peter Anvin @ 2006-05-24 21:23 UTC (permalink / raw)
  To: sparclinux

David Miller wrote:
> 
> GLIBC is the source of all knowledge :-)
> 
> libc/sysdeps/unix/sysv/linux/sparc/sparc64/sigaction.c
> 
> In there you'll see that you have to set the sa_restorer
> to NULL and pass in the "stub" address minus 8, as the
> 4th argument to rt_sigation system call.
> 

Minus 8 :)  Talk about weirdness... :-/

	-hpa

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: sigreturn on sparc64
  2006-05-24 18:00 sigreturn on sparc64 H. Peter Anvin
  2006-05-24 21:21 ` David Miller
  2006-05-24 21:23 ` H. Peter Anvin
@ 2006-05-24 21:34 ` David Miller
  2006-05-24 22:02 ` H. Peter Anvin
  3 siblings, 0 replies; 5+ messages in thread
From: David Miller @ 2006-05-24 21:34 UTC (permalink / raw)
  To: sparclinux

From: "H. Peter Anvin" <hpa@zytor.com>
Subject: Re: sigreturn on sparc64
Date: Wed, 24 May 2006 14:23:58 -0700

> David Miller wrote:
> > 
> > GLIBC is the source of all knowledge :-)
> > 
> > libc/sysdeps/unix/sysv/linux/sparc/sparc64/sigaction.c
> > 
> > In there you'll see that you have to set the sa_restorer
> > to NULL and pass in the "stub" address minus 8, as the
> > 4th argument to rt_sigation system call.
> > 
> 
> Minus 8 :)  Talk about weirdness... :-/

The stub is "returned to" directly from the signal handler itself
using the "retl" instruction, which jumps to the value of "register
%i7 plus 8".  We stick the passed in stub address directly into the
%i7 register of the signal handler frame, that's why you need to
subtract 8 for the system call argument.

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: sigreturn on sparc64
  2006-05-24 18:00 sigreturn on sparc64 H. Peter Anvin
                   ` (2 preceding siblings ...)
  2006-05-24 21:34 ` David Miller
@ 2006-05-24 22:02 ` H. Peter Anvin
  3 siblings, 0 replies; 5+ messages in thread
From: H. Peter Anvin @ 2006-05-24 22:02 UTC (permalink / raw)
  To: sparclinux

David Miller wrote:
> The stub is "returned to" directly from the signal handler itself
> using the "retl" instruction, which jumps to the value of "register
> %i7 plus 8".  We stick the passed in stub address directly into the
> %i7 register of the signal handler frame, that's why you need to
> subtract 8 for the system call argument.

Yup, there are a lot of things like this in the Linux ABI (something which makes sense on 
one architecture, but not across architectures); sigreturn is obviously the worst.

	-hpa

^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2006-05-24 22:02 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2006-05-24 18:00 sigreturn on sparc64 H. Peter Anvin
2006-05-24 21:21 ` David Miller
2006-05-24 21:23 ` H. Peter Anvin
2006-05-24 21:34 ` David Miller
2006-05-24 22:02 ` H. Peter Anvin

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.