* Re: Signal handler arguments
2009-03-09 16:28 Signal handler arguments Elad Lahav
@ 2009-03-10 0:06 ` David Miller
2009-03-10 2:54 ` Elad Lahav
` (3 subsequent siblings)
4 siblings, 0 replies; 6+ messages in thread
From: David Miller @ 2009-03-10 0:06 UTC (permalink / raw)
To: sparclinux
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.
^ permalink raw reply [flat|nested] 6+ messages in thread* Re: Signal handler arguments
2009-03-09 16:28 Signal handler arguments Elad Lahav
2009-03-10 0:06 ` David Miller
@ 2009-03-10 2:54 ` Elad Lahav
2009-03-10 3:39 ` David Miller
` (2 subsequent siblings)
4 siblings, 0 replies; 6+ messages in thread
From: Elad Lahav @ 2009-03-10 2:54 UTC (permalink / raw)
To: sparclinux
> 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
^ permalink raw reply [flat|nested] 6+ messages in thread* Re: Signal handler arguments
2009-03-09 16:28 Signal handler arguments Elad Lahav
2009-03-10 0:06 ` David Miller
2009-03-10 2:54 ` Elad Lahav
@ 2009-03-10 3:39 ` David Miller
2009-03-10 12:00 ` Elad Lahav
2009-03-10 12:17 ` David Miller
4 siblings, 0 replies; 6+ messages in thread
From: David Miller @ 2009-03-10 3:39 UTC (permalink / raw)
To: sparclinux
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.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Signal handler arguments
2009-03-09 16:28 Signal handler arguments Elad Lahav
` (2 preceding siblings ...)
2009-03-10 3:39 ` David Miller
@ 2009-03-10 12:00 ` Elad Lahav
2009-03-10 12:17 ` David Miller
4 siblings, 0 replies; 6+ messages in thread
From: Elad Lahav @ 2009-03-10 12:00 UTC (permalink / raw)
To: sparclinux
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
^ permalink raw reply [flat|nested] 6+ messages in thread* Re: Signal handler arguments
2009-03-09 16:28 Signal handler arguments Elad Lahav
` (3 preceding siblings ...)
2009-03-10 12:00 ` Elad Lahav
@ 2009-03-10 12:17 ` David Miller
4 siblings, 0 replies; 6+ messages in thread
From: David Miller @ 2009-03-10 12:17 UTC (permalink / raw)
To: sparclinux
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.
^ permalink raw reply [flat|nested] 6+ messages in thread