> Since a new release of gdb is being prepared, maybe this is the time
> to get a debugger that also knows about the floating point processor
> of the 486 or better processors.
>
> Unfortunately, it seems that 2.0 and 2.1 have diverged in the
> ptrace interface: where 2.0.33 allows PEEKUSR and POKEUSR to access
> the FP registers, 2.1.82 has GETFPREGS and SETFPREGS. (One historical
> note: when 2.0 was initially released, there was no way for a debugger
> to find out what the FPU state is).
I cannot decide which will be the official interface, I just can state my
opinion.
GDB should not use PEEKUSR/POKEUSR either for floating point registers
or for normal registers.
GDB should use the GETREGS/SETREGS for normal registers and
GETFPREGS/SETFPREGS for floating point registers.
This interface is more clean, since it hides the internal representation
of the processor state. It is more efficient, because it allows a debugger
to download the full state of a process with two system calls.
Juan Cespedes' library call tracer (libtrace, similar to strace, available
at ftp.etsit.upm.es:/pub/sistemas/Linux/local/ltrace_0.0.1.tar.gz) will be
improved with this interface.
I implemented the PEEKUSR/POKEUSR interface because I needed floating
point debugging for my work. Therefore, I looked at the method used for
getting normal registers, and extended it for getting floating point
registers. It required more work in the kernel and less work in the gdb
part. However, downloading the state of the floating point unit requires
several system calls.
With regard to my patches, even when I endorse Bill's patches, you have of
course my permission to use them. I doubt that my GDB patches can be
copyrighted, since there are less that 10 lines of code in them. The
new file tm-linux.h is essentialy a copy of tm-cygwin32.h. Therefore, I
think that I should not have to fill the copyright transfer papers.
However, if you think that for some strange reason you should my approach
rather that Bill's one and you also think that my patches are significant
and therefore I must sign FSF papers, please let me know.
I should be useful to implement the GETREGS/SETREGS/GETFPREGS/SETFPREGS in
Linux 2.0, so that GDB 4.17 can implement this interface without
compatibility problems with the kernel 2.0.
Ramon