From: torvalds@klaava.Helsinki.FI (Linus Torvalds) Subject: Re: What arguments to Linux signal handler? Date: 7 Aug 1993 12:17:02 +0300
In article <1993Aug6.193328.10936@palantir.p.tvt.se> atoeno1@ato.abb.se writes:
>
>General question:
>What are the arguments to a signal handler in Linux? In SunOS
>it's:
> void handler(sig, code, scp, addr)
> int sig, code;
> struct sigcontext *scp;
> char *addr; ,
>, in Utlrix it's the same but without the 'addr'. But what
>about Linux? There doesn't seem to be any definition of
>'sigcontext' in signal.h or any other include file. Does
>my system (SLS 1.01) miss something, or is Linux different
>from SunOS and Ultrix when it comes to signals?
The only thing I guarantee will work is
void handler(int sig);
but newer kernels actually try to conform to iBCS2 to some degree, so
the signal stack looks like this:
void handler(int sig, struct sigcontext sc);
where 'struct sigcontext' looks like this:
struct sigcontext {
unsigned short gs, __gsh;
unsigned short fs, __fsh;
unsigned short es, __esh;
unsigned short ds, __dsh;
unsigned long edi;
unsigned long esi;
unsigned long ebp;
unsigned long __esp;
unsigned long ebx;
unsigned long edx;
unsigned long ecx;
unsigned long eax;
unsigned long trapno; (***)
unsigned long err; (***)
unsigned long eip;
unsigned short cs, __csh;
unsigned long eflags;
unsigned long esp;
unsigned short ss, __ssh;
struct i387_hard * i387; (***)
};
where the (***) entries are currently not filled in by linux.
Note that the above is not a complete state save: linux has some further
info on the stack for internal use, and you should not use the stack
information to return to the "pre-signal" state by hand, as linux may
want to do further processing of the signal in the signal return handler
(which is also built on the stack - not exactly self-modifying code, but
self-generating).
Also note that the "reason" for the signal ('trapno' and 'err') which
tell you why the signal happened are not usable right now, and the
address of the page fault ('%cr2') is not saved at all nor does it seem
to be covered by iBCS2. Also, the 387 state, which could be useful, is
not saved, so the extended stack information is not very useful as-is.
I'll have to do all of the above, but they are rather low on my list of
priorities.
Linus