[Peter Holzer <hp@quasi.vmars.tuwien.ac.at> writes:]
>> My plan is to use the Plan9-style of signal handling. Because this
>> specifies that signal handling completion happen with an explicit
>> call (as opposed to UNIX, where you do a subroutine return), there is
>> no need to do that trampoline hackery.
>I don't think it makes much difference, whether the signal handler
>itself calls sigreturn (or whatever it is called) or falls into it.
I hope you mean it doesn't make much difference for purposes of floating
point emulation performance. It makes a BIG difference in the simplicity
of the signal handling model. Without the user calling a known interface
to complete signal handling, you have the problem of what return address
to place on his stack. You can't just return to the interrupted code
stream, because on most architectures you need to do an "iret", not
just a "ret". Other actions may also be required.
So where do you point to get the necessary code? There is no location
in the user process which is known ahead of time. HP/UX has the C
library register the location of said "trampoline" code. Exactly
*where* in the C library was the source of a couple really subtle
bugs. Alternatively, BSD has often placed the U area in the user's
address space, put the trampoline code there, and pointed to that as
the return address from the signal handler.
I think Plan9's technique is far preferable, so we'll run with that as
far as possible.
Andy
Received on Mon Oct 18 10:28:01 1993
This archive was generated by hypermail 2.1.8 : Wed Sep 21 2005 - 19:37:12 PDT