This is the mail archive of the gdb-patches@sourceware.org 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


> Date: Thu, 2 Oct 2008 07:15:31 -0700
> From: "H.J. Lu" <hjl.tools@gmail.com>
> 
> On Thu, Oct 2, 2008 at 3:26 AM, Mark Kettenis <mark.kettenis@xs4all.nl> wrote:
> >> Date: Thu, 18 Sep 2008 10:27:28 -0700
> >> From: "H.J. Lu" <hongjiu.lu@intel.com>
> >>
> >> Hi,
> >>
> >> Intel AVX extends 128bit XMM registers to 256bit YMM registers. I
> >> am enclosing a propose to add YMM register support in gdb.  Since
> >> there is no AVX hardware, we can only implement the remote debug
> >> with AVX emulator.
> >>
> >> This patch extends gdb remote protocol for AVX, based on Daniel's
> >> patch to auto-detect ia32 and x86-64 executables:
> >>
> >> http://sources.redhat.com/ml/gdb-patches/2006-11/msg00056.html
> >>
> >> I tested it by setting x86_sse_unit to avx in gdbserver/i387-fp.c.  OK
> >> to install?
> >
> > Had some time to learn about AVX yesterday.  I noticed that the %ymm
> > registers partially overlap with the %xmm registers, and that while
> 
> xmm register is the alias of the lower 128bit of ymm register.

Indeed, and GDB should implement it as such.

> > Intel obviously is trying to deprecate the old SSE stuff, the
> > instructions will still be present.  As such, I think the goal:
> >
> >> 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
also not sure that debug info that refers to the %xmm registers will
continue to work.

> >> 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
that needs a bit more thought to make sure we don't surprise our
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).

Mark


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