Gareth Hughes <gareth@precisioninsight.com> writes:
> If we change the definition of ucontext_t to contain both the mcontext_t
> structure and, instead of _libc_fpstate, we inline the
> _libc_fpstate_fsave structure, then the size of ucontext_t will not
> change and thus will remain binary compatible.
>
> A couple of notes:
>
> - The FPU data may be incorrectly interpreted by old applications that
> haven't been updated to recongize the new FXSAVE format, but will not
> segfault as ucontext_t hasn't changed size. The FPU data should be
> dereferenced from the fpregset_t pointer and not the inlined
> __fpregs_mem member.
>
> - Applications that are smart enought to look for the magic field will
> be able to correctly determine the FPU save format, and will still not
> segfault.
I completely fail to see how this can help. This is the situation for
the segfault:
stack end --> fsave context end
...
fsave context begin <---\
|
sigcontext end |
... |
sigcontext begin |
stack low --> |
|
The fpregs element of mcontext_t points here |. This means the
`magic' number is beyond the end of the stack. You have to have a
sign that the fxsave context is used in the area of the old struct.
And I repeat: the csseg element seems to be an adequate candidate.
Replacing _libc_fpstate with _libc_fpstate_fsave in ucontext_t is fine
(and necessary) but it's not all.
> As for munging the data to include both formats in one go, this is
> really not nice and makes the signal context setup code rather ugly and
> slow, which defeats the overall purpose of a _fast_ FPU save and
> restore.
That's not true. fxsave is mainly there to descrease context
switching time (and supporting the SSE registers). Delivering signals
is a very slow process and a few more cycles spend on setting up data
structures do not really matter. I already said I would complain too
much if the old fp state is left alone and initialized with all zeroes
or so. But the stack layout should look something like this:
stack end --> fxsave context end
...
fxsave context begin
fsave context end
...
fsave context begin
sigcontext end
...
sigcontext begin
stack low -->
I.e., _libc_fpstate should be defined as
struct _libc_fpstate
{
struct _libc_fpstate_fsave fsave;
struct _libc_fpstate_fxsave fxsave;
};
The ucontext_t struct could stay as it is (after replacing
_libc_fpstate with _libc_fpstate_fsave) even though the memory for
the__fpregs_mem part is allocated as a _libc_fpstate object (i.e.,
will also include the fxsave stuff).
magic should go somewhere else (csseg or wherever). Note that csseg
would automatically be zero if you clear the fsave struct in case
there is a fxsave struct.
-- ---------------. drepper at gnu.org ,-. 1325 Chesapeake Terrace Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA Red Hat `--' drepper at redhat.com `------------------------- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Wed Jun 07 2000 - 21:00:24 EST