This is the mail archive of the
mailing list for the glibc project.
Re: Is it possible to preserve flags for fetestexcept() inside signalhandler
On 6/7/2012 4:46 PM, Jed Brown wrote:
> On Thu, Jun 7, 2012 at 12:54 PM, Carlos O'Donell
> <email@example.com> wrote:
>> You must not call fetestexcept() from a signal handler since it is
>> not async-signal safe.
>> Unfortunately there isn't any infrastructure in glibc to do what
>> you want.
> Okay, thank you. If there is an opportunity to support this use case,
> it would save a lot of time in some HPC scenarios where it's expensive
> to get a core file or a debugging session.
Sorry, I didn't mean to make it sound so grim.
If this is something that's useful to you then you'll need to figure
out what's going wrong.
Unfortunately the ISO C standard is against you on this and in general
doesn't require any of the FPU functions to be accessible from a signal
handler. Therefore you'll get push-back from the kernel and glibc on the
issue. To persevere you'll need to show that this is the best solution
to the problem you're trying to solve.
For example: Why can't you use systemtap to solve your debugging problem?
The answer might be: Because this is easier to setup.
- Determine why fetestexcept doesn't work from a signal handler.
Looking at sysdeps/i386/fpu/ftestexcept.c, it seems like it *should*
just work from a signal, but it's likely the kernel saves but doesn't
restore this state when it delivers the signal. I suggest you go talk
to the kernel people about this.
fetestexcept (int excepts)
int xtemp = 0;
/* Get current exceptions. */
__asm__ ("fnstsw %0" : "=a" (temp));
/* If the CPU supports SSE we test the MXCSR as well. */
if ((GLRO(dl_hwcap) & HWCAP_I386_XMM) != 0)
__asm__ ("stmxcsr %0" : "=m" (*&xtemp));
return (temp | xtemp) & excepts & FE_ALL_EXCEPT;
Mentor Graphics / CodeSourcery
+1 (613) 963 1026