This is the mail archive of the
mailing list for the GDB project.
Re: _fpstate_fxsave & al
- To: gareth at precisioninsight dot com
- Subject: Re: _fpstate_fxsave & al
- From: Mark Kettenis <kettenis at wins dot uva dot nl>
- Date: Wed, 7 Jun 2000 14:41:10 +0200 (MET DST)
- CC: gdb at sourceware dot cygnus dot com
- References: <200006061357.PAA09891@landau.wins.uva.nl> <393E5832.firstname.lastname@example.org>
[ Forwarded to email@example.com; this thread started as a
discussion on support for the pentium III SSE registers in Linux
2.4.0, but this message mainly deals with improving GDB's support
for them. ]
Date: Wed, 07 Jun 2000 08:12:02 -0600
From: Gareth Hughes <firstname.lastname@example.org>
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.
Okay, I've thought about this and rather than try and change GDB I'll
just add the PTRACE_GETXMMREGS (which will be defined to the same as
PTRACE_GETXFPREGS) request and the corresponding core dump note (again,
defined as NT_PRXMMREG/NT_PRXFPREG).
Great, although I still think that XFP is more appropriate than XMM.
I won't bother submitting my work unless you'd like to see fixes for a
couple of things:
If it's not too much trouble please send in the patches. I might not
use them as is, but I might get some useful idea's from them.
- XMM registers shouldn't be displayed with an 'info registers' command.
Sounds reasonable, but they should be shown by `info all-registers',
and there should be something like `info simd-registers', to display
the XMM registers. We should be careful in choosing the name for this
command. It might be desirable to use the same command to display
similar registers on other targets (PPC Altivec comes to mind), in
that case the name shouldn't be too Intel-specific.
- XMM registers should be displayed with either an 'info float' or 'info
simd-float' or similar command. They should be in a format similar to
the 5.0 FP registers, with status/control register info and IEEE float
info (NAN, Inf etc).
I'd rather not add them to `info float', since its output would
probably be too long to fit on one screen on a 25-line terminal. But
`info simd-float' sounds fine.
What do you think? The points about binary compatibility with PEEKUSER
etc are important, and I guess I can live with two PTRACE options if it
is the sanest way to do things.
Sounds fine. Yes we really need the two PTRACE requests.