Re: [PATCH] More updates to FXSR/SSE support in 2.4.0-test1

[Gareth Hughes <gareth at precisioninsight dot com>]

Mark Kettenis wrote:
> 
>    Date: Sun, 11 Jun 2000 18:03:41 -0600
>    From: Gareth Hughes <gareth@precisioninsight.com>
> 
>    Here's a copy of my latest work, this time kernel and glibc headers
>    only.  I'm still working on updating GDB, as incorporating Mark's
>    suggestions leads to some problems with the stock 5.0 code (mainly in
>    the interpretation of the FPU tag word).
> 
> Looks much better :-).  I didn't realize there were tag word problems
> until yesterday :-(.  If this means that stock GDB 5.0 won't work
> anymore, so be it.  A sane kernel interface is more important.

I agree.  I'm happy with this as it's correct, fast *and* backward
compatible.  Thanks again everyone for pulling me up on the third point
:-)

> What exactly happens if you try to compile stock GDB 5.0 with the new
> kernel?  Does it compile at all?  Is it seriously crippled?  Or does
> it basically work right?

It works (kind of), it's just extracting the FPU register data
incorrectly and then misinterpreting the tag word and thus
incorrectlying interpreting the incorrect data :-).  It's a pretty
trivial patch, the extraction fix is contained in my last patch and I've
just got to copy the tag word conversion code across.  Should have a
patch in a couple of hours - busy with work at the moment.

> If there are major problems, it might be wise to choose a different
> name for the PTRACE_{GET,SET}XFPREGS requests to avoid confusion.
> That way, nobody will end up with a non-functional GDB (of course the
> blame lies entirely with the GDB team for this mess).  My suggestion
> would be to call those requests PTRACE_{GET,SET}FPXREGS.  It turns out
> that Unixware uses a similar name for its FXSR support (they don't
> have ptrace(), but they have a PCSFPXREG ioctl() and a __fpxregset_t
> type[1]).  Moreover this makes the FSAVE/FPREGS vs. FXSAVE/FPXREGS
> analogy a bit more explicit.

I like this idea, makes a whole lot more sense.  This is kinda what I
was arguing for way back in our previous emails.  It also matches up
nicely with the signal handling types I've declared.  It would be good
to get a working GDB 5.0 with a patch rather than a broken one when you
haven't patched it.  The standard PTRACE_{GET|SET}FPREGS works fine as
it stands, and in many cases this will be good enough.  When is the next
release of GDB planned for?

I'd like some clarification on core dumping - will it be okay to add a
new note NT_PRFPXREG, a new elf type elf_fpxregset_t and so on?  If so,
I'll add this to the kernel and my GDB 5.0 patch and fire it off today.

-- Gareth