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
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
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:
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
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
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.
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
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
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
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
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:
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.)
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,
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:
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
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
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
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
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
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,
"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
Hi,
I want my signal handler to return from a SIGFPE and continue normal
execution right _after_ the instruction that caused the signal.
My first attempt workes quite well: I just modify the EIP register
though the ucontext pointer being passed to the signal handler:
void fpeHandler(int,
Hi,
I want my signal handler to return from a SIGFPE and continue normal
execution right _after_ the instruction that caused the signal.
My first attempt workes quite well: I just modify the EIP register
though the ucontext pointer being passed to the signal handler:
void fpeHandler(int,
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
24 matches
Mail list logo
