This is the mail archive of the
libc-alpha@sourceware.cygnus.com
mailing list for the glibc project.
Re: [Hakon.Bugge@scali.com] libc/1739: signal+siglongjmp destroys FP control word on x86
- To: aj at suse dot de
- Subject: Re: [Hakon.Bugge@scali.com] libc/1739: signal+siglongjmp destroys FP control word on x86
- From: Mark Kettenis <kettenis at wins dot uva dot nl>
- Date: Mon, 15 May 2000 16:44:29 +0200 (MET DST)
- CC: libc-alpha at sourceware dot cygnus dot com, Hakon dot Bugge at scali dot com
- References: <u8vh0frj5y.fsf@gromit.rhein-neckar.de>
From: Andreas Jaeger <aj@suse.de>
Date: 15 May 2000 16:18:33 +0200
Hi glibc folks,
We've received the appended bug report about signal/siglongjmp.
Hakon is right, we don't save anything at all about the FPU.
And doing so would have a considerable penalty, especially for
programs that don't use the FPU, since it kills the lazy FPU handling
in the kernel, and makes context switches more expensive for those
programs.
Looking at the description of setjmp in ISO C 1999, I found:
The environment of a call to the setjmp macro consists of
information sufficient for a call to the longjmp function to
return execution to the correct block and invocation of that
block, were it called recursively. It does not include the
state of the floating-point status flags, of open files, or of
any other component of the abstract machine.
Since siglongjmp is an extension of setjmp/longjmp only with respect
to signal handling, it seems that I can close the bug report with the
comment "You're right - but we're following the ISO C standard which
explictly forbids this".
What do you think?
I think your answer is excellent!
Mark