Date: Wed, 07 Jun 2000 07:47:41 -0600
From: Gareth Hughes <gareth@precisioninsight.com>
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.
It seems to be the simplest, clearest way to do things. No `magic'
struct members, you just get what you ask for: PTRACE_GETFPREGS gives
you the state as stored by FSAVE, PTRACE_GETXFPREGS gives you the
state as stored by FXSAVE. If PTRACE_GETXFPREGS fails with EIO you
know that the extra stuff (such as the SSE registers) isn't supported.
Why not use something like PTRACE_GETXMMREGS? Isn't that what they are?
Since PTRACE_GET{XFP,XMM}REGS would get you a FXSAVE area, the
XMM/SSE/SIMD registers are only a part of the data. You also get the
traditional FPU state. Moreover there are still quite a few unused
bytes in the FXSAVE area, that Intel might use for other purposes in
the future. IMHO XMM is too narrow (although I'm not sure what the
letters are supposed to mean). You can probably say the same
for XFP, although here I'll argue that the X stands for eXtended.
Also think about FSAVE vs. FXSAVE and FPREGS vs. XFPREGS; you just add
an `X'.
Anyway, it's just a name. It'd be nice if we could find the name that
is the most expressive about what it actually does. Personally I
think XFP is slightly better than XMM, and wouldn't change it since
GDB already uses those names.
> 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.
Any specific complaints besides those mentioned in your other mail?
I'll probably rewrite some parts of i386-linux-nat.c (again :-() for
GDB 5.1, to share a little more code among the i386 targets.
> 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?
Using extra notes for additional registers is the approach taken by
Solaris. Instead of reinventing the wheel, adopting this approach
makes a lot of sense, especially since it will allow some binutiles
code to be reused.
I just noticed that NT_PRXFPREG doesn't have the value 5, but rather a
random looking number. Looks like someone wanted to delay choosing
the definitive number. I guess one has to be chosen right now, but
I'm not sure what the "official" procedure on getting such a number
is. Coordination with the binutils maintainers is essential (you can
reach them at binutils@sourceware.cygnus.com). I also wonder what the
ELF specs have to say about this.
> 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.
Thanks. I don't own a Pentium III, so I won't be able to test 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.
I'm in charge of GDB. Please send patches to
gdb-patches@sourceware.cygnus.com. There is also
gdb@sourceware.cygnus.com for more general discussions.
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:28 EST