Re: _fpstate_fxsave & al

[Gareth Hughes <gareth at precisioninsight dot com>]

Mark Kettenis wrote:
> 
>    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,
>    defined as NT_PRXMMREG/NT_PRXFPREG).
> 
> Great, although I still think that XFP is more appropriate than XMM.

I guess this is probably the most minor of the discussion points, and
I'll be willing to concede on it if we have nice SSE debugging support
:-)

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

Okay, will do.

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

My thoughts exactly.  The way I've implemented it includes them in the
'info all-registers' command, and I was planning on adding an 'info
simd-registers' or 'info simd-float' command as an experiment.

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

My thoughts exactly.  'info simd-float' it is then.

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

Yes, I agree :-)  The more I think about it the more I like the fact
that two PTRACE requests removes the need for any kind of magic number. 
This is definitely a Good Thing.

I'm more than willing to help contribute to this work for 5.1, as I want
to ensure the kernel/glibc/GDB support for SSE is done correctly and
robustly.  I think we're well on the way to acheiving that.

-- Gareth