* accessing stacked FPU state in 32-bit SIGFPE handler?
@ 2016-05-07 15:50 Mikael Pettersson
2016-05-07 17:44 ` David Miller
2016-05-07 18:35 ` Mikael Pettersson
0 siblings, 2 replies; 3+ messages in thread
From: Mikael Pettersson @ 2016-05-07 15:50 UTC (permalink / raw)
To: sparclinux
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.
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: accessing stacked FPU state in 32-bit SIGFPE handler?
2016-05-07 15:50 accessing stacked FPU state in 32-bit SIGFPE handler? Mikael Pettersson
@ 2016-05-07 17:44 ` David Miller
2016-05-07 18:35 ` Mikael Pettersson
1 sibling, 0 replies; 3+ messages in thread
From: David Miller @ 2016-05-07 17:44 UTC (permalink / raw)
To: sparclinux
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.
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: accessing stacked FPU state in 32-bit SIGFPE handler?
2016-05-07 15:50 accessing stacked FPU state in 32-bit SIGFPE handler? Mikael Pettersson
2016-05-07 17:44 ` David Miller
@ 2016-05-07 18:35 ` Mikael Pettersson
1 sibling, 0 replies; 3+ messages in thread
From: Mikael Pettersson @ 2016-05-07 18:35 UTC (permalink / raw)
To: sparclinux
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.
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2016-05-07 18:35 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2016-05-07 15:50 accessing stacked FPU state in 32-bit SIGFPE handler? Mikael Pettersson
2016-05-07 17:44 ` David Miller
2016-05-07 18:35 ` Mikael Pettersson
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.