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: Andreas Jaeger <aj at suse dot de>
- Subject: Re: [Hakon.Bugge@scali.com] libc/1739: signal+siglongjmp destroys FP control word on x86
- From: "H . J . Lu" <hjl at lucon dot org>
- Date: Mon, 15 May 2000 08:43:14 -0700
- Cc: libc-alpha Mailinglist <libc-alpha at sourceware dot cygnus dot com>,Hakon dot Bugge at scali dot com
- References: <u8vh0frj5y.fsf@gromit.rhein-neckar.de>
On Mon, May 15, 2000 at 04:18:33PM +0200, Andreas Jaeger wrote:
>
> 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.
>
> 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?
>
For those who care, I have a kernel patch for the problem.
H.J.