On Wed, 16 Apr 1997, Mike Jagdis wrote:
> On 15 Apr 1997, Miguel de Icaza wrote:
> > Applications should be able to specify at sigaction time whether they
> > want to have a siginfo_t/ucontext_t passed to the signal handler or
> > not.
>
> You always get a ucontext whether you want it or not because that
> is what gets restored when the handler returns. Whether you declare
> it in the handler's argument list is up to you. The prototype for
> a standard handler only specifies a single int argument (although
> this may depend on which standard you read recently :-) ).
But what "ucontext" the handler gets is the point.
For non-SA_SIGINFO, this is pseudo-hidden on the user's stack (ie. the
handler does not get a pointer to it, but its format/offset is cover by
iBCS2).
Luckily, iBCS2 doesn't cover the stack-frame format for SA_SIGINFO
signals, so we are free on the format (but it would be benefical if it is
compatible with SCO).
SVID-III covers only the basic format of the ucontext_t structure, but it
is _not_ compatible with the iBCS2 signal version.
> Anyway, _if_ the old handler requires a ucontext at all then it
> is defined as taking (int, ucontext_t *) where the second argument
> is a pointer to a completely implementation specific chunk of data.
Cannot do this for old handlers. They need to be iBCS2 compliant, and so
need to use the iBCS2 signal frame (which includes the 'old' ucontext).
> Since anything that touches this at all must be specifically
> coded to a given kernel it doesn't seem like that big a deal to
> actually always use the three argument form and avoid complicating
> things? (Apparently iBCS2 wants a ucontext as standard but since
> it points to implementation specific data does it _really_ matter
> that much?)
For SA_SIGINFO (and SA_ONSTACK) we could use an 'extended' signal frame
format.
For handlers iBCS2 handlers we ensure they see the same stack-frame as
before. No worries.
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
------------------------------------------------------------------