Bug 74298 - the signal handler's ucontext doesn't get any FPU state
Summary: the signal handler's ucontext doesn't get any FPU state
Status: RESOLVED FIXED
Alias: None
Product: valgrind
Classification: Developer tools
Component: general (other bugs)
Version First Reported In: 2.1 CVS
Platform: Unlisted Binaries Linux
: NOR normal
Target Milestone: ---
Assignee: Jeremy Fitzhardinge
URL:
Keywords:
: 86641 (view as bug list)
Depends on:
Blocks:
 
Reported: 2004-02-05 23:51 UTC by Jeremy Fitzhardinge
Modified: 2005-01-18 23:45 UTC (History)
3 users (show)

See Also:
Latest Commit:
Version Fixed/Implemented In:
Sentry Crash Report:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Jeremy Fitzhardinge 2004-02-05 23:51:28 UTC
When a signal handler for CPU excepton is called, it gets passed a ucontext
structure, which contains the CPU state at the time of the exception.  Valgrind
doesn't pass the handler any FPU/SSE related information; the fpstate pointer is
left NULL.

This makes Mesa-6.0 crash, because it looks at the fpstate when it's checking
that SSE is properly supported.
Comment 1 Dirk Mueller 2004-02-14 20:27:04 UTC
confirmed.
Comment 2 Jeremy Fitzhardinge 2004-03-12 04:54:53 UTC
Well, this turns out to be tricky to fix, at least for Mesa.  Mesa wants to do the hardest of all things - it wants to take an FPU exception, inspect the up-to-date FP state in the handler, then modify it, returning to the original instruction.

Valgrind really isn't set up for this.  Firstly, because of bug 69530, we can't give up-to-date FPU state to the handler.  Secondly, the signal frame is constructed so that there are two copies of the VCPU state - one for the handler to see, and one which is used to restore the state when the handler returns, so if the handler does change the state, it isn't the one which takes effect.

The second problem can be fixed reasonably easily, but the first is much harder.  The workaround we can apply now is to save the FP state before each potentially faulting instruction, but this is hard work and potentially a huge performance hit.

Not really sure what to do here.
Comment 3 Jeremy Fitzhardinge 2004-03-13 03:30:57 UTC
Well, it can be made to work, but only if you use --single-step=yes.
Comment 4 Tom Hughes 2004-08-05 22:04:15 UTC
*** Bug 86641 has been marked as a duplicate of this bug. ***
Comment 5 Tom Hughes 2005-01-04 16:33:28 UTC
*** Bug 95667 has been marked as a duplicate of this bug. ***
Comment 6 Jeremy Fitzhardinge 2005-01-18 23:45:20 UTC
OK, signal handlers now get state.  You still need to use --single-step=yes if you want accurately inspect/modify it from the handler (as Mesa wants to do).