This is the mail archive of the mailing list for the GDB project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: PATCH: Extend gdb remote protocol for AVX

On Sat, Oct 4, 2008 at 1:49 PM, Mark Kettenis <> 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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]