Signal handler arguments

Signal handler arguments

[Elad Lahav]

According to the man page (which, I believe, conforms to the POSIX standard), 
the third argument in a signal handler should be a pointer to a ucontext 
structure (assuming the SA_SIGINFO flag was passed to sigaction). However, under 
Sparc64, the kernel passes a pointer to a sigcontext structure (see line 472 in 
arch/sparc64/kernel/signal.c). This incompatibility should be either fixed or 
documented.

--Elad

Re: Signal handler arguments

[David Miller]

From: Elad Lahav <elad_lahav@users.sourceforge.net>
Date: Mon, 09 Mar 2009 12:28:31 -0400

> According to the man page (which, I believe, conforms to the POSIX standard), the third argument in a signal handler should be a pointer to a ucontext structure (assuming the SA_SIGINFO flag was passed to sigaction). However, under Sparc64, the kernel passes a pointer to a sigcontext structure (see line 472 in arch/sparc64/kernel/signal.c). This incompatibility should be either fixed or documented.

It's passing a siginfo_t as both the second and third argument:

struct rt_signal_frame {
	struct sparc_stackf	ss;
	siginfo_t		info;
    ...
static inline void
setup_rt_frame(struct k_sigaction *ka, struct pt_regs *regs,
	       int signo, sigset_t *oldset, siginfo_t *info)
{
    ...
	struct rt_signal_frame __user *sf;
    ...
	regs->u_regs[UREG_I0] = signo;
	regs->u_regs[UREG_I1] = (unsigned long) &sf->info;
	/* The sigcontext is passed in this way because of how it
	 * is defined in GLIBC's /usr/include/bits/sigcontext.h
	 * for sparc64.  It includes the 128 bytes of siginfo_t.
	 */
	regs->u_regs[UREG_I2] = (unsigned long) &sf->info;

The sigaction man page says:

              struct sigaction {
                  void     (*sa_handler)(int);
                  void     (*sa_sigaction)(int, siginfo_t *, void *);
                  sigset_t   sa_mask;
                  int        sa_flags;
                  void     (*sa_restorer)(void);
              }

The actual type of the third argument is architecture independant,
that is why it is defined as "void *" rather than a specific type.

Which is effectively a "sigcontext" which on sparc64 is defined as a
structure containing a siginfo_t then the register information.  See
/usr/include/bits/sigcontext.h

Yes it says ucontext_t and sparc is the lone-wolf out here.

Re: Signal handler arguments

[Elad Lahav]

> The actual type of the third argument is architecture independant,
> that is why it is defined as "void *" rather than a specific type.
No. It is always a pointer to a ucontext_t structure. The *details* of 
this structure are architecture-dependent. Please refer to page 1339 in

1003.1TM
Standard for Information Technology
Portable Operating System Interface (POSIX)
System Interfaces, Issue 6
Approved 12 September 2001
The Open Group

> Yes it says ucontext_t and sparc is the lone-wolf out here.
It's not a lone wolf, it's a misguided one.

--Elad

Re: Signal handler arguments

[David Miller]

From: Elad Lahav <elad_lahav@users.sourceforge.net>
Date: Mon, 09 Mar 2009 22:54:26 -0400

> > Yes it says ucontext_t and sparc is the lone-wolf out here.
> It's not a lone wolf, it's a misguided one.

Well, whatever it is it can't be changed without breaking
everything out there if that's what you are suggesting
happen.

Re: Signal handler arguments

[Elad Lahav]

David Miller wrote:
> From: Elad Lahav <elad_lahav@users.sourceforge.net>
> Date: Mon, 09 Mar 2009 22:54:26 -0400
> 
>>> Yes it says ucontext_t and sparc is the lone-wolf out here.
>> It's not a lone wolf, it's a misguided one.
> 
> Well, whatever it is it can't be changed without breaking
> everything out there 
Do you mean breaking all the applications that use the third parameter 
as a sigcontext structure? Can you point to any? Remember that this is 
an undocumented deviation from the POSIX standard, unique to 
Linux/Sparc. Somehow I have a feeling that very few programs are aware 
of this feature and are using it.

 > if that's what you are suggesting happen.
I suggested that this deviation should be either changed *or* documented.

--Elad

Re: Signal handler arguments

[David Miller]

From: Elad Lahav <e2lahav@gmail.com>
Date: Tue, 10 Mar 2009 08:00:58 -0400

> David Miller wrote:
> > Well, whatever it is it can't be changed without breaking
> > everything out there 
>
> Do you mean breaking all the applications that use the third
> parameter as a sigcontext structure? Can you point to any? Remember
> that this is an undocumented deviation from the POSIX standard,
> unique to Linux/Sparc. Somehow I have a feeling that very few
> programs are aware of this feature and are using it.

GCC's dwarf unwinder knows the exact layout, as does MONO's sparc
backend, GDB, etc...

The list goes on and on.

It can't be changed without breaking lots of things.

Since this is machine specific code anyways, I can't see this
causing any kind of real problem once the programmer knows what
the type of that third argument is.