[Hakon.Bugge@scali.com] libc/1739: signal+siglongjmp destroys FP control word on x86

Mark Kettenis kettenis@wins.uva.nl
Mon May 15 07:44:00 GMT 2000


   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


More information about the Libc-alpha mailing list