accessing stacked FPU state in 32-bit SIGFPE handler?

accessing stacked FPU state in 32-bit SIGFPE handler?

[Mikael Pettersson]

What is the approved way of accessing the stacked FPU state from a
SIGFPE handler (sigaction + SA_SIGINFO) in a 32-bit process?  I need
to update parts of that state.

The third parameter to the handler is a sigcontext pointer, but the
struct ends just before the stacked fpu_save pointer.  Also, the type
that fpu_save points to doesn't appear to be defined by glibc's headers.

I could duplicate the kernel's types (32-bit __siginfo_fpu_t and struct
rt_signal_frame), but that feels a bit unsafe unless there's a statement
that they form a de-facto ABI.

Re: accessing stacked FPU state in 32-bit SIGFPE handler?

[David Miller]

From: Mikael Pettersson <mikpelinux@gmail.com>
Date: Sat, 7 May 2016 17:50:32 +0200

> What is the approved way of accessing the stacked FPU state from a
> SIGFPE handler (sigaction + SA_SIGINFO) in a 32-bit process?  I need
> to update parts of that state.
> 
> The third parameter to the handler is a sigcontext pointer, but the
> struct ends just before the stacked fpu_save pointer.  Also, the type
> that fpu_save points to doesn't appear to be defined by glibc's headers.
> 
> I could duplicate the kernel's types (32-bit __siginfo_fpu_t and struct
> rt_signal_frame), but that feels a bit unsafe unless there's a statement
> that they form a de-facto ABI.

You can be sure the on-stack signal saved state layout won't change,
otherwise gdb, exception unwinding, and a host of other things would
break.

Re: accessing stacked FPU state in 32-bit SIGFPE handler?

[Mikael Pettersson]

David Miller writes:
 > From: Mikael Pettersson <mikpelinux@gmail.com>
 > Date: Sat, 7 May 2016 17:50:32 +0200
 > 
 > > What is the approved way of accessing the stacked FPU state from a
 > > SIGFPE handler (sigaction + SA_SIGINFO) in a 32-bit process?  I need
 > > to update parts of that state.
 > > 
 > > The third parameter to the handler is a sigcontext pointer, but the
 > > struct ends just before the stacked fpu_save pointer.  Also, the type
 > > that fpu_save points to doesn't appear to be defined by glibc's headers.
 > > 
 > > I could duplicate the kernel's types (32-bit __siginfo_fpu_t and struct
 > > rt_signal_frame), but that feels a bit unsafe unless there's a statement
 > > that they form a de-facto ABI.
 > 
 > You can be sure the on-stack signal saved state layout won't change,
 > otherwise gdb, exception unwinding, and a host of other things would
 > break.

Thanks, that works for me.