Re: _fpstate_fxsave & al

From: Mark Kettenis (kettenis@wins.uva.nl)
Date: Tue Jun 06 2000 - 08:57:36 EST


   From: Gareth Hughes <gareth@precisioninsight.com>
   Date: Tue, 06 Jun 2000 12:54:07 +1000

   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.

That's all fine and dandy, but you're breaking binary compatibility,
just to save a few bytes of kernel code. Users will see GDB crashing
when they upgrade to Linux 2.4.0. That's unacceptable.

The only way to avoid this is adding another ptrace(2) request:

Suggested name: PTRACE_GETXFPREGS
Suggested format: The format used by the FXSAVE instruction,
                        *including* the reserved space after the SSE
                        registers.

It would be a good idea if you'd still implement the PTRACE_GETFPREGS
when using FXSAVE, converting the relevant bits to FSAVE format. This
will keep old programs fully functional. That shouldn't be hard, but
if people really don't want that a zeroed out buffer wouldn't do too
much harm.

On processors that don't have the FXSAVE instruction the new
PTRACE_GETXFPREGS request should return EIO, and the PTRACE_GETFPREGS
request should be fully supported.

   I was planning on submitting this work once the kernel patch was
   applied. I think multiple PTRACEs is a bad idea.

Speaking as the native maintainer of GDB on Linux/x86:

GDB 5.0 already includes support for the SSE registers (see
gdb/i386-linux-nat.c). Using the name suggested above for the new
ptrace(2) request, combined with an appropriate definition of `struct
user_xfpregs_struct' in the appropriate glibc header, would mean that
simply recompiling GDB 5.0 would be enough to get a GDB that can view
the SSE registers (probably at the cost of displaying some garbage for
some of the FPU control registers, but that can be fixed in GDB 5.1).

GDB 5.0 and the upcoming binutils 2.10 also include support for the
SSE registers in core files (see bfd/elf.c). They expect to see a
note named "LINUX" of type 5 (NT_PRXFPREG). Things would just work if
the note's contents would use the same layout as the PTRACE_GETXFPREGS
request.

One last issue: please make sure that you don't change the location of
u_debugreg array in `struct user'. I believe the current patch does
changes its location, which will break binary compatibility for the
PTRACE_PEEKUSER and PTRACE_POKEUSER requests, and break hardware
watchpoint support in GDB. And if Linux 2.4.0 still supports a.out
core-dumps, you'll have to make sure you don't break those too.

Mark

-
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:25 EST