Ulrich Drepper wrote:
>
> 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
I've got a copy of GDB that doesn't need a new PTRACE option. It works fine
with pre-2.4 kernels and the 2.4 kernel using the standard GET_FPREGS ptrace
option.
I was planning on submitting this work once the kernel patch was applied. I
think multiple PTRACEs is a bad idea.
> - 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.
Yes it does work, it's just not binary compatible. You need the 2.4.0 kernel
and corresponding glibc for the PIII FPU context, if you are using an old kernel
there is nothing sane that we can do. The old kernel will simple fill in the
_fpstate struct (which is the same as the new _fpstate_fsave struct) and thus if
your libc or application is expecting something different you haven't compiled
it properly. An application should never try and access the magic field, unless
it has been compiled for and is running on the 2.4 kernel. Such applications
are simply not compatible with an old, pre-2.4 kernel.
There are only two cases here - current kernel, libc and application, and 2.4
kernel, libc and application. You can't mix an old kernel/libc with a new
application and vice versa.
I don't see what the problem is here. Surely that's the definition of binary
incompatibility.
> 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
I don't see why we need this. Again, if you want to access the FPU state, you
need to update your application to handle the binary incompatibility. Moving
the magic around isn't going to help when an old kernel fills in the
cssel/status with a non-zero value which is interpreted as a FXSAVE FPU format.
> 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.
I've been running the 2.4.0 test kernel with this patch applied and have not had
any problems. There is one simple case that needs to be handled - if you want
to interact with the FPU state, then you need to be aware of what kernel you
will be running on. If you are targetting a pre-2.4 kernel, then you use the
old sigcontext headers. If you are targetting a 2.4 kernel, then you use the
new sigcontext headers. Once you've been compiled, you can't run on a kernel
that uses the other sigcontext.
This really seems like a fairly simple problem, and trying to come up with an
intricate workaround will only confuse the issue. Applications that want to
interact with the FPU state, or sigcontexts, should at build time check for 2.4
kernel headers and include the appropriate code for compilation. They must run
on the 2.4 kernel and corresponding libc (which should include the headers I
sent you). There is really no other sane way to handle the new FPU save
format. Trying to allow pre-2.4 kernels to run with a 2.4 libc or application
(or other combination) simply will not work.
-- Gareth
-
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