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/
This archive was generated by hypermail 2b29 : Wed Jun 07 2000 - 21:00:26 EST