This is the mail archive of the mailing list for the GDB project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: _fpstate_fxsave & al

[ Forwarded to; 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 <>

   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,

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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]