There are currently two problems with the PIII math support:
- already reported by others, we need a new PTRACE command to get the
extended state instead of the old one. Not doing this affects binary
compatibility
- the way the kernel currently uses a mgic word in struct _fpstate does
not work. Assume an application which has to test for this after the
kernel set up an old-style context (be it an old kernel or not a PIII).
if (ctx->fpstate.magic == 0)
...old format
else
...new format
The problem is the memory access to `magic'. If the context is written
near the upper end of the stack this access might cause an SEGFAULT or
lead to other bogus results since
offsetof(struct _fpstate, magic) > sizeof(struct _fpstate_fsave)
The SEGFAULT can appear since the struct _fpstate_fsave can be placed
at the end of the stack (think sigaltstack). The bogus result can
appear on old kernels where, by accident, the addressed word higher up
on the stack is 1 and the application would assume it has to handle a PIII.
The only possible solution is to have the magic word in the range of the
old struct _fpstate_fsave. I see two possibilities:
+ use a zero value for cssel to signal the new format. cssel never can
be zero and it's a rather uninteresting field anyway. For many
applications (if any) are looking at it
+ use the `status' member. I don't know offhand which value cannot be
found in this field in regular use but there should be some
Both problems are showstoppers so somebody please work on it. Also,
the documentation should clearly say that there are still binary
incompatible changes and people who don't want to debug, change and
recompile their applications should not use the PIII option. One
incompatibility is code which uses floating-point exception handling
and is investigating the contents of the floating-point registers.
-- ---------------. 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:23 EST