Messages in this thread | | | Date | Mon, 14 Apr 1997 20:05:30 +0100 (BST) | From | Mark Hemment <> | Subject | Re: why do we put code onto the stack when doing a signal? |
| |
Hi,
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 stack.
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!!!).
Regards,
markhe
------------------------------------------------------------------ Mark Hemment, Unix/C Software Engineer (Contractor) markhe@nextd.demon.co.uk http://www.nextd.demon.co.uk/ "Success has many fathers, failure is a B**TARD!" - anon ------------------------------------------------------------------
| |