lkml.org 
[lkml]   [1999]   [Oct]   [28]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectDebugging support for Pentium Streaming SIMD Extensions

Intel has contracted with Cygnus to add support for the Streaming
SIMD Extensions in GCC, GDB, and so on. I've been working on the GDB
side of things. I started with Doug Ledford's patches against 2.2.9,
adapted them to 2.2.12, and extended ptrace to provide access to the
SSE registers. They are available from:

http://sourceware.cygnus.com/gdb/papers/linux

The next GDB snapshot, available on Monday or Tuesday, will include
some support for examining SSE registers, etc. GDB snapshots are
available from a link on this page:

http://sourceware.cygnus.com/gdb

The patches here are preliminary, and I'm interested in hearing folks'
comments on them. We're going to give our final version of these
patches to Intel, and Intel is going to announce them in some way, and
publicly contribute them to Linux. So we would very much like to get
the patches in a form the kernel maintainers would actually approve
of.


Points of interest:

* I've added two new requests to ptrace: PTRACE_{GET,SET}XFPREGS
read and write a process's i387_hard_fxsave structure. These new
requests are parallel to the existing PTRACE_{GET,SET}{,FP}REGS
requests.

I think these changes are backward-compatible in the right ways. If
the processor doesn't support SSE, or the kernel was configured
without SSE support, then ptrace returns EIO, just as an older
kernel would if presented with an unrecognized ptrace request.
GDB adapts to old and new kernels just fine, and old GDB's should
continue to work unchanged.

I've submitted corresponding patches to GLIBC to add the structure
and ptrace request to <sys/ptrace.h> and <sys/user.h>.

* The patch doesn't extend core dumps to include the SSE registers
yet. I assume that the best way to do this is to add a new note,
with some new type name like "NT_PRXFPREG", containing an
i387_hard_fxsave structure. This would be in addition to an
old-style NT_PRFPREG note, so all existing tools would continue to
work. Naturally, this note would only be dumped if the kernel and
processor supported it.

* To save a process's context, these patches do both an fnstenv and
an fxsave, even though fxsave saves all the context necessary.
Thus, context switches are slower than they need to be.

The rationale for the extra save, I think, is that several external
interfaces --- signal contexts, core dumps, and ptrace --- use the
old FP save format, but reconstructing an fstenv record from an
fxsave record is non-trivial (although possible). By saving the
FP/SSE state in both formats, it's easy to retain compatibility with
those old interfaces.

I think Linux should simply use fxsave and fxrstor for context
switches, and convert between that and the fnstenv format when
needed. The conversion is quick, but not as quick as a memcpy; see
the description of the FXSAVE instruction for details.

However, I don't think the cost is important. These conversions
would occur in three places:

- When dumping core. The cost of doing a single conversion is
inconsequential next to the cost of writing the core file.

- When a process makes a PTRACE_{GET,SET}FPREGS request. New code
can use PTRACE_{GET,SET}XFPREGS instead, so this is also not a
problem.

- When the kernel delivers a signal, or restores a signal context.
A conversion is necessary if the kernel wants to continue to use
the existing struct _fpstate. However, I believe that struct
_fpstate must be expanded to include the XMM registers as well.
If we do this, we might as well change it to use the new format at
the same time, so no conversion will be necessary.

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

\
 
 \ /
  Last update: 2005-03-22 13:54    [W:0.033 / U:0.044 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site