Re: X86 fpu registers in a signal handler's ucontext
On 04/29/2013 07:34 AM, Warlich, Christof wrote: > Second, only FP state seems to be available through ucontext_t, and I would > need to clear exceptions for SSE as well. Not true. > Can anyone give me some advice on how to I could proceed? To optimize the common case, if the signal handler doesn't touch the FPU the state is not reloaded from the signal stack. Therefore you need to execute an FPU instruction -- pretty much any FPU instruction -- in your signal handler in order to force the reload. -hpa -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: X86 fpu registers in a signal handler's ucontext
Warlich, Christof writes: > richard -rw- weinberger writes: > > Are you telling us that Ubuntu shipped the wrong header file? > > Hmm - at least I still don't know how to get the right definition > of uc_mcontext (with eglibc-2.13 on Ubuntu 11.10) ... > > If I include both signal.h and asm-generic/ucontext.h, gcc reports > this error: > > /usr/include/asm-generic/ucontext.h:4:8: error: redefinition of 'struct > ucontext' > /usr/include/i386-linux-gnu/sys/ucontext.h:119:16: error: previous > definition of 'struct ucontext' > > Thus, signal.h obviously includes the wrong i386-linux-gnu/sys/ucontext.h > defining uc_mcontext to be of type mcontext_t. > > So is it still me doing something wrong or or _did_ Ubuntu ship > the wrong header files? #include #include has worked for my SIGFPE handlers on Linux for the last 10+ years on various distros and target architectures. Can we stop this thread now? There is no _kernel_ issue here. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: X86 fpu registers in a signal handler's ucontext
richard -rw- weinberger writes: > Are you telling us that Ubuntu shipped the wrong header file? Hmm - at least I still don't know how to get the right definition of uc_mcontext (with eglibc-2.13 on Ubuntu 11.10) ... If I include both signal.h and asm-generic/ucontext.h, gcc reports this error: /usr/include/asm-generic/ucontext.h:4:8: error: redefinition of 'struct ucontext' /usr/include/i386-linux-gnu/sys/ucontext.h:119:16: error: previous definition of 'struct ucontext' Thus, signal.h obviously includes the wrong i386-linux-gnu/sys/ucontext.h defining uc_mcontext to be of type mcontext_t. So is it still me doing something wrong or or _did_ Ubuntu ship the wrong header files?-- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: X86 fpu registers in a signal handler's ucontext
richard -rw- weinberger writes: > Are you telling us that Ubuntu shipped the wrong header file? Grmpf ... no. :-* Here again, I obviously started looking at the wrong file (i386-linux-gnu/sys/ucontext.h), which defines uc_mcontext to be of type mcontext_t. So the right header to be used seems to be asm-generic/ucontext.h, which _does_ include the right definition of uc_mcontext to be of type struct sigcontext even in Ubuntu 11.10. Thanks again and sorry for the confusion, I hope I have my lesson learned. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: X86 fpu registers in a signal handler's ucontext
On Thu, May 2, 2013 at 7:42 AM, Warlich, Christof wrote: > Mikael Pettersson writes: >> You're looking at the wrong header: glibc-2.17/sysdeps/i386/sys/ucontext.h >> is legacy SVR4. >> Instead look at glibc-2.17/sysdeps/unix/sysv/linux/x86/sys/ucontext.h. >> >> (If the old one got installed on your system then something there is >> seriously wrong.) > > Oh-oh: It looks like my system was simply too old: Initially, I was looking > at Ubuntu 11.10 > with an eglibc-2.13, and a double-check with a newly downloaded glibc-2.17 > lead me to the > wrong file. Are you telling us that Ubuntu shipped the wrong header file? -- Thanks, //richard -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: X86 fpu registers in a signal handler's ucontext
On Thu, May 2, 2013 at 7:42 AM, Warlich, Christof christof.warl...@siemens.com wrote: Mikael Pettersson mi...@it.uu.se writes: You're looking at the wrong header: glibc-2.17/sysdeps/i386/sys/ucontext.h is legacy SVR4. Instead look at glibc-2.17/sysdeps/unix/sysv/linux/x86/sys/ucontext.h. (If the old one got installed on your system then something there is seriously wrong.) Oh-oh: It looks like my system was simply too old: Initially, I was looking at Ubuntu 11.10 with an eglibc-2.13, and a double-check with a newly downloaded glibc-2.17 lead me to the wrong file. Are you telling us that Ubuntu shipped the wrong header file? -- Thanks, //richard -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: X86 fpu registers in a signal handler's ucontext
richard -rw- weinberger richard.weinber...@gmail.com writes: Are you telling us that Ubuntu shipped the wrong header file? Grmpf ... no. :-* Here again, I obviously started looking at the wrong file (i386-linux-gnu/sys/ucontext.h), which defines uc_mcontext to be of type mcontext_t. So the right header to be used seems to be asm-generic/ucontext.h, which _does_ include the right definition of uc_mcontext to be of type struct sigcontext even in Ubuntu 11.10. Thanks again and sorry for the confusion, I hope I have my lesson learned. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: X86 fpu registers in a signal handler's ucontext
richard -rw- weinberger richard.weinber...@gmail.com writes: Are you telling us that Ubuntu shipped the wrong header file? Hmm - at least I still don't know how to get the right definition of uc_mcontext (with eglibc-2.13 on Ubuntu 11.10) ... If I include both signal.h and asm-generic/ucontext.h, gcc reports this error: /usr/include/asm-generic/ucontext.h:4:8: error: redefinition of 'struct ucontext' /usr/include/i386-linux-gnu/sys/ucontext.h:119:16: error: previous definition of 'struct ucontext' Thus, signal.h obviously includes the wrong i386-linux-gnu/sys/ucontext.h defining uc_mcontext to be of type mcontext_t. So is it still me doing something wrong or or _did_ Ubuntu ship the wrong header files?-- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: X86 fpu registers in a signal handler's ucontext
Warlich, Christof writes: richard -rw- weinberger richard.weinber...@gmail.com writes: Are you telling us that Ubuntu shipped the wrong header file? Hmm - at least I still don't know how to get the right definition of uc_mcontext (with eglibc-2.13 on Ubuntu 11.10) ... If I include both signal.h and asm-generic/ucontext.h, gcc reports this error: /usr/include/asm-generic/ucontext.h:4:8: error: redefinition of 'struct ucontext' /usr/include/i386-linux-gnu/sys/ucontext.h:119:16: error: previous definition of 'struct ucontext' Thus, signal.h obviously includes the wrong i386-linux-gnu/sys/ucontext.h defining uc_mcontext to be of type mcontext_t. So is it still me doing something wrong or or _did_ Ubuntu ship the wrong header files? #include signal.h #include ucontext.h has worked for my SIGFPE handlers on Linux for the last 10+ years on various distros and target architectures. Can we stop this thread now? There is no _kernel_ issue here. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: X86 fpu registers in a signal handler's ucontext
On 04/29/2013 07:34 AM, Warlich, Christof wrote: Second, only FP state seems to be available through ucontext_t, and I would need to clear exceptions for SSE as well. Not true. Can anyone give me some advice on how to I could proceed? To optimize the common case, if the signal handler doesn't touch the FPU the state is not reloaded from the signal stack. Therefore you need to execute an FPU instruction -- pretty much any FPU instruction -- in your signal handler in order to force the reload. -hpa -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: X86 fpu registers in a signal handler's ucontext
Mikael Pettersson writes: > You're looking at the wrong header: glibc-2.17/sysdeps/i386/sys/ucontext.h is > legacy SVR4. > Instead look at glibc-2.17/sysdeps/unix/sysv/linux/x86/sys/ucontext.h. > > (If the old one got installed on your system then something there is > seriously wrong.) Oh-oh: It looks like my system was simply too old: Initially, I was looking at Ubuntu 11.10 with an eglibc-2.13, and a double-check with a newly downloaded glibc-2.17 lead me to the wrong file. Many thanks for your help! -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: X86 fpu registers in a signal handler's ucontext
Mikael Pettersson mi...@it.uu.se writes: You're looking at the wrong header: glibc-2.17/sysdeps/i386/sys/ucontext.h is legacy SVR4. Instead look at glibc-2.17/sysdeps/unix/sysv/linux/x86/sys/ucontext.h. (If the old one got installed on your system then something there is seriously wrong.) Oh-oh: It looks like my system was simply too old: Initially, I was looking at Ubuntu 11.10 with an eglibc-2.13, and a double-check with a newly downloaded glibc-2.17 lead me to the wrong file. Many thanks for your help! -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: X86 fpu registers in a signal handler's ucontext
Warlich, Christof writes:
> Mikael Pettersson writes:
> > Write to the fpstate ->mxcsr and ->swd fields in the sigaction handler's
> > uc_mcontext.
>
> To me, "sigaction handler's uc_mcontext" sounds like userspace, which really
> confuses me:
> Even in most recent glibc-2.17, uc_mcontext is of type mcontext_t, which us
> defined as:
>
> typedef struct {
> gregset_t gregs;
> fpregset_t fpregs;
> } mcontext_t;
>
> typedef struct fpregset {
> union {
> struct fpchip_state {
> int state[27];
> int status;
> } fpchip_state;
> struct fp_emul_space {
> char fp_emul[246];
> char fp_epad[2];
> } fp_emul_space;
> int f_fpregs[62];
> } fp_reg_set;
> long int f_wregs[33];
> } fpregset_t;
>
> So there is no fpstate whatsoever.
You're looking at the wrong header: glibc-2.17/sysdeps/i386/sys/ucontext.h is
legacy SVR4.
Instead look at glibc-2.17/sysdeps/unix/sysv/linux/x86/sys/ucontext.h.
(If the old one got installed on your system then something there is seriously
wrong.)
The only quirk is that to access ->mxcsr on 32-bit you have to check if the
high half of
->status contains FXSR_MAGIC and if so you need to cast that pointer to struct
_fpstate*.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: X86 fpu registers in a signal handler's ucontext
Mikael Pettersson writes:
> Write to the fpstate ->mxcsr and ->swd fields in the sigaction handler's
> uc_mcontext.
To me, "sigaction handler's uc_mcontext" sounds like userspace, which really
confuses me:
Even in most recent glibc-2.17, uc_mcontext is of type mcontext_t, which us
defined as:
typedef struct {
gregset_t gregs;
fpregset_t fpregs;
} mcontext_t;
typedef struct fpregset {
union {
struct fpchip_state {
int state[27];
int status;
} fpchip_state;
struct fp_emul_space {
char fp_emul[246];
char fp_epad[2];
} fp_emul_space;
int f_fpregs[62];
} fp_reg_set;
long int f_wregs[33];
} fpregset_t;
So there is no fpstate whatsoever.
However, these elements seem to be available in the uc_mcontext definition of
the
kernel, but I can't have a sigaction handler there, can I? Then, how does the
kernel's uc_mcontext definition help me in my (userspace) signal handler?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: X86 fpu registers in a signal handler's ucontext
Warlich, Christof writes: > Andi Kleen writes: > > The FP registers are restored lazily, but the state for this is kept in > > the kernel. > > I'm not sure if I understand "lazily" in this context: Do you mean that FP > registers _are_ restored within the kernel, but _not_ from a (possibly > modified) > ucontext of a userspace signal handler? If so, do you know a reason why the > GP > registers are so nicely restored from userspace, but not the FP registers? > > > One easy way may be to catch the FPU exception too and clear from there? > > Hmm - I _do_ catch SIGFPE in my userspace signal handler, but I obviously > can't clear the FP exceptions from there. This, together with your answer > so far, makes me conclude that there may be no way to achieve my goal from > userspace, right :-(? Write to the fpstate ->mxcsr and ->swd fields in the sigaction handler's uc_mcontext. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: X86 fpu registers in a signal handler's ucontext
Andi Kleen writes: > The FP registers are restored lazily, but the state for this is kept in > the kernel. I'm not sure if I understand "lazily" in this context: Do you mean that FP registers _are_ restored within the kernel, but _not_ from a (possibly modified) ucontext of a userspace signal handler? If so, do you know a reason why the GP registers are so nicely restored from userspace, but not the FP registers? > One easy way may be to catch the FPU exception too and clear from there? Hmm - I _do_ catch SIGFPE in my userspace signal handler, but I obviously can't clear the FP exceptions from there. This, together with your answer so far, makes me conclude that there may be no way to achieve my goal from userspace, right :-(? Ok, still assuming I'm (terribly) right so far: The kernel calls do_coprocessor_error() when the FP exception occurs. As I don't want to patch the kernel, is there a "best practise" way to hook my module code into the FP exception handler? The only way that comes to my mind is modifying the vector table in modul_init() to let the FP exception point to my code and restoring it in module_exit(). > There can be some complications with different save formats too (XSAVE > vs FXSAVE). So your solution may not be necessarily 100% portable > to all systems. Yes, I'm certainly arch specific in many ways here, but that wouldn't be much of a problem for me though.-- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: X86 fpu registers in a signal handler's ucontext
Andi Kleen a...@firstfloor.org writes: The FP registers are restored lazily, but the state for this is kept in the kernel. I'm not sure if I understand lazily in this context: Do you mean that FP registers _are_ restored within the kernel, but _not_ from a (possibly modified) ucontext of a userspace signal handler? If so, do you know a reason why the GP registers are so nicely restored from userspace, but not the FP registers? One easy way may be to catch the FPU exception too and clear from there? Hmm - I _do_ catch SIGFPE in my userspace signal handler, but I obviously can't clear the FP exceptions from there. This, together with your answer so far, makes me conclude that there may be no way to achieve my goal from userspace, right :-(? Ok, still assuming I'm (terribly) right so far: The kernel calls do_coprocessor_error() when the FP exception occurs. As I don't want to patch the kernel, is there a best practise way to hook my module code into the FP exception handler? The only way that comes to my mind is modifying the vector table in modul_init() to let the FP exception point to my code and restoring it in module_exit(). There can be some complications with different save formats too (XSAVE vs FXSAVE). So your solution may not be necessarily 100% portable to all systems. Yes, I'm certainly arch specific in many ways here, but that wouldn't be much of a problem for me though.-- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: X86 fpu registers in a signal handler's ucontext
Warlich, Christof writes: Andi Kleen a...@firstfloor.org writes: The FP registers are restored lazily, but the state for this is kept in the kernel. I'm not sure if I understand lazily in this context: Do you mean that FP registers _are_ restored within the kernel, but _not_ from a (possibly modified) ucontext of a userspace signal handler? If so, do you know a reason why the GP registers are so nicely restored from userspace, but not the FP registers? One easy way may be to catch the FPU exception too and clear from there? Hmm - I _do_ catch SIGFPE in my userspace signal handler, but I obviously can't clear the FP exceptions from there. This, together with your answer so far, makes me conclude that there may be no way to achieve my goal from userspace, right :-(? Write to the fpstate -mxcsr and -swd fields in the sigaction handler's uc_mcontext. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: X86 fpu registers in a signal handler's ucontext
Mikael Pettersson mi...@it.uu.se writes:
Write to the fpstate -mxcsr and -swd fields in the sigaction handler's
uc_mcontext.
To me, sigaction handler's uc_mcontext sounds like userspace, which really
confuses me:
Even in most recent glibc-2.17, uc_mcontext is of type mcontext_t, which us
defined as:
typedef struct {
gregset_t gregs;
fpregset_t fpregs;
} mcontext_t;
typedef struct fpregset {
union {
struct fpchip_state {
int state[27];
int status;
} fpchip_state;
struct fp_emul_space {
char fp_emul[246];
char fp_epad[2];
} fp_emul_space;
int f_fpregs[62];
} fp_reg_set;
long int f_wregs[33];
} fpregset_t;
So there is no fpstate whatsoever.
However, these elements seem to be available in the uc_mcontext definition of
the
kernel, but I can't have a sigaction handler there, can I? Then, how does the
kernel's uc_mcontext definition help me in my (userspace) signal handler?
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: X86 fpu registers in a signal handler's ucontext
Warlich, Christof writes:
Mikael Pettersson mi...@it.uu.se writes:
Write to the fpstate -mxcsr and -swd fields in the sigaction handler's
uc_mcontext.
To me, sigaction handler's uc_mcontext sounds like userspace, which really
confuses me:
Even in most recent glibc-2.17, uc_mcontext is of type mcontext_t, which us
defined as:
typedef struct {
gregset_t gregs;
fpregset_t fpregs;
} mcontext_t;
typedef struct fpregset {
union {
struct fpchip_state {
int state[27];
int status;
} fpchip_state;
struct fp_emul_space {
char fp_emul[246];
char fp_epad[2];
} fp_emul_space;
int f_fpregs[62];
} fp_reg_set;
long int f_wregs[33];
} fpregset_t;
So there is no fpstate whatsoever.
You're looking at the wrong header: glibc-2.17/sysdeps/i386/sys/ucontext.h is
legacy SVR4.
Instead look at glibc-2.17/sysdeps/unix/sysv/linux/x86/sys/ucontext.h.
(If the old one got installed on your system then something there is seriously
wrong.)
The only quirk is that to access -mxcsr on 32-bit you have to check if the
high half of
-status contains FXSR_MAGIC and if so you need to cast that pointer to struct
_fpstate*.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: X86 fpu registers in a signal handler's ucontext
"Warlich, Christof" writes: > > First, this link: > http://valgrind.10908.n7.nabble.com/need-FPU-and-SSE-state-in-sigcontext-ucontext-td19844.html > suggests that unlike the GPRs, the FP registers are _not_ restored after > returnung from the signal handler. The FP registers are restored lazily, but the state for this is kept in the kernel. One easy way may be to catch the FPU exception too and clear from there? There can be some complications with different save formats too (XSAVE vs FXSAVE). So your solution may not be necessarily 100% portable to all systems. -Andi -- a...@linux.intel.com -- Speaking for myself only -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: X86 fpu registers in a signal handler's ucontext
Warlich, Christof christof.warl...@siemens.com writes: First, this link: http://valgrind.10908.n7.nabble.com/need-FPU-and-SSE-state-in-sigcontext-ucontext-td19844.html suggests that unlike the GPRs, the FP registers are _not_ restored after returnung from the signal handler. The FP registers are restored lazily, but the state for this is kept in the kernel. One easy way may be to catch the FPU exception too and clear from there? There can be some complications with different save formats too (XSAVE vs FXSAVE). So your solution may not be necessarily 100% portable to all systems. -Andi -- a...@linux.intel.com -- Speaking for myself only -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
