Linux-kernel mailing list archive 2000-23,: Re: _fpstate_fxsave & al

# Re: _fpstate_fxsave & al

Gareth Hughes (gareth@precisioninsight.com)
Wed, 07 Jun 2000 07:47:41 -0600

- Messages sorted by: [ date ][ thread ][ subject ][ author ]
- Next message: Kenneth C. Arnold: "Re: "/sbin/init" source code"
- Previous message: Ulrich Drepper: "Re: _fpstate_fxsave & al"
- Maybe in reply to: Ulrich Drepper: "_fpstate_fxsave & al"
- Next in thread: Gareth Hughes: "Re: _fpstate_fxsave & al"

Mark Kettenis wrote:
>
> 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.

It's trivial to do it either way, and if you really think that two
PTRACE options is the best way to do it I will add this support in. I'm
still deciding if I like this or not. I've seen the kernel patches to
support this.

Why not use something like PTRACE_GETXMMREGS? Isn't that what they are?

> 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).

Yes, I'm aware of this. I'm just not sure if I agree with how it's been
implemented.

> 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.

When I first saw this I really didn't like it, but thinking about it I
suppose it's the cleanest way and certainly the most backward-compatible
way to do it. Why is it called NT_PRXFPREG? Why not NT_PRXMMREG?
Isn't that what they are?

> 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.

You're correct. I will fix this.

Who's in charge of the GDB/binutils changes? For niceness, I'll make
the current GDB source code compile and work with my kernel changes, but
I'd like to at least fix the XFP -> XMM reg naming.

-- 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/

- Next message: Kenneth C. Arnold: "Re: "/sbin/init" source code"
- Previous message: Ulrich Drepper: "Re: _fpstate_fxsave & al"
- Maybe in reply to: Ulrich Drepper: "_fpstate_fxsave & al"
- Next in thread: Gareth Hughes: "Re: _fpstate_fxsave & al"