Re: PATCH: Extend gdb remote protocol for AVX

["H.J. Lu" <hjl dot tools at gmail dot com>]

On Sat, Oct 4, 2008 at 1:49 PM, Mark Kettenis <mark.kettenis@xs4all.nl> wrote:
>> >> 1. Only display YMM registers, no XMM registers if the execution
>> >> environment supports AVX, independent of executables.
>> >
>> > is wrong.  People should still be able to debug traditional SSE code
>> > even if the execution environment supports AVX.  Since the following
>> > goals follow from #1:
>>
>> You can still debug SSE code with my proposal.
>
> Sure, but statements like "print $xmm0" won't work anymore.  And I'm

That is true. We can solve it the same way as al/ax/eax.

> also not sure that debug info that refers to the %xmm registers will
> continue to work.

It works the same way as al/ax/eax/rax. Gdb sees the same register
number for al/ax/eax/rax. We tell them apart by their sizes. There are
not many differences in the way how we deal with xmm/ymm.

>> >> 2. Native:
>> >>    a. Check native AVX support at run-time.
>> >>    b. Use AVX registers only if native environment supports AVX.
>> >>    Otherwise use XMM registers.
>> >> 3. Remote:
>> >>    a. Check remote AVX support when setting up connection.
>> >>    b. Use AVX registers only if remote environment supports AVX.
>> >>    Otherwise use XMM registers.
>> >
>> > I disagree with those as well.
>> >
>> > We probably need to play pseudo-register tricks to make sure %xmm and
>> > %ymm share the data for the lower 128 bits in the register cache, and
>> > perhaps some option to choose between showing %xmm, %ymm or both in
>> > the "info registers" output.
>> >
>>
>> The relationship between xmm and ymm is similar to eax and rax.
>
> Not really.  We treat amd64 and i386 as different ISA's much in the
> same way as we treat sparc and sparc64 as different ISA's.  I can
> understand that Intel would like to position AVX as something
> radically different, but essentially it is just another extensions to
> the amd64 and i386 ISA's.
>
> If there would be a desire on amd64 to be able to refer to the 32-bit
> parts of the general-purpose registers we would implement them in much
> the same way as I propose for %xmm/%ymm, as pseudo registers.
>
>> My proposal only deals with how to access xmm/ymm registers and
>> doesn't affect other aspects. What does your suggestion will buy us
>> beyond my proposal?
>
> I have no objection to the changes you proposed for the remote
> protocol.  But your diff also touches the core register stuff, and

I only increased MAX_REGISTER_SIZE to 32. All other changes
are limited to x86. A big part of my change is to auto-detect packet size.

> that needs a bit more thought to make sure we don't surprise our

Only "print %xmm" won't work on AVX.  It is easy to support "print %xmm"
on AVX if gdb supports "print %al/%ax". But I see it as a separate
issue which is orthogonal to my AVX proposal.

> users.  At that point, it may be easier to use the same model for the
> remote protocol, where you transfer the top 128 bits of the %ymm
> registers in addition to the %xmm registers.  Adter all this is how
> the hardware does it too (xsave is just an extension of fxsave).
>

Ymm register is 256bit. Transfer top 128 bits of the ymm registers
separately will require bigger changes without much benefit.


-- 
H.J.