Mark Kettenis wrote:
>
> 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.
Okay, I can live with that. Certainly makes backward compatibility a
non-issue.
> 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.
I'm just being pedantic I guess, but it would be nice to at least have
some reference to either the FXSR or XMM cpuid bits, as this is what
Intel calls it. The first time I saw reference to XFP I didn't know it
referred to the FXSAVE FPU save format. In a perfect world, this would
be so, but seeing as it's already been named XFP I guess we can just
leave it at that.
> 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.
I've thought about the PTRACE options a lot today, and I'm agreeing with
the current GDB code a little more now ;-) As long as there's a nice,
clean way for GDB to get access to the SSE registers I'm happy.
> 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.
If it's been done already, then I feel a lot better about this. I just
didn't want us to have to hack ELF to make it work. If this, and the
two PTRACE requests, means we can get away without a magic field then
it's a Good Thing.
> Thanks. I don't own a Pentium III, so I won't be able to test this :-(.
No probs, I'll make sure it runs fine on my end. I've got the latest
CVS of GDB and will verify my changes tomorrow. I've got a lot of other
work to do at the moment so I didn't get the updates finished, but I'll
send out patches tomorrow. The changes are very minor and trivial, so
there shouldn't be any problems.
Thanks again for your input.
-- Gareth
-
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:29 EST