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
------------------------------------------------------------------