Re: why do we put code onto the stack when doing a signal?

Mark Hemment (
Mon, 14 Apr 1997 20:05:30 +0100 (BST)


On Mon, 14 Apr 1997, Ingo Molnar wrote:
> the x86 case:
> __put_user(0x0000b858, CODE(0)); /* popl %eax ; movl $,%eax */
> __put_user(0x80cd0000, CODE(4)); /* int $0x80 */
> __put_user(__NR_sigreturn, CODE(2));
> this looks like the only code that is put onto the stack. This is a static
> sequence of instructions, why cant we put this into a shared read-only,
> executable mmap()-ed area? [say into libc].

That's do-able at the moment, you need to set-up a special call-gate for
libc to return back into the kernel. Infact, having a call-gate (rather
than using the system call-gate) is not a bad idea - it can remove
a bit of unnecessary overhead.

There is one catch.
When SA_SIGINFO is implemented, we can have a different number of
arguments on the stack-frame for a signal handler. (SA_SIGINFO adds two
extra arguments, a "siginfo_t *" and "ucontext_t *" - I must find time to
do this...).
A libc signal return function would need to act as the signal-handler
caller, which can be difficult as it wouldn't know how may args are on the

SVR4 use to (maybe it still does) use this method - it was v. ugly (all
signals were delievered to a single library function, which called the
appriopate handler!!!).



Mark Hemment, Unix/C Software Engineer (Contractor)
"Success has many fathers, failure is a B**TARD!" - anon