From: Mark Kettenis <mark.kettenis@xs4all.nl>
To: hjl.tools@gmail.com
Cc: gdb-patches@sourceware.org, dan@codesourcery.com
Subject: Re: PATCH: Extend gdb remote protocol for AVX
Date: Thu, 02 Oct 2008 10:29:00 -0000 [thread overview]
Message-ID: <200810021026.m92AQMqC006955@brahms.sibelius.xs4all.nl> (raw)
In-Reply-To: <20080918172728.GA12703@lucon.org> (hongjiu.lu@intel.com)
> 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
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:
> 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.
next prev parent reply other threads:[~2008-10-02 10:29 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-09-18 17:28 H.J. Lu
2008-09-18 17:51 ` Mark Kettenis
2008-09-18 18:20 ` Mark Kettenis
2008-09-18 18:31 ` H.J. Lu
2008-09-18 18:34 ` Daniel Jacobowitz
2008-09-18 19:03 ` H.J. Lu
2008-09-18 19:39 ` Daniel Jacobowitz
2008-09-18 20:13 ` H.J. Lu
2008-09-18 20:24 ` Daniel Jacobowitz
2008-10-02 10:29 ` Mark Kettenis [this message]
2008-10-02 14:16 ` H.J. Lu
2008-10-04 20:52 ` Mark Kettenis
2008-10-04 22:14 ` Daniel Jacobowitz
2008-10-05 14:37 ` H.J. Lu
2008-10-06 21:35 ` Mark Kettenis
2008-10-07 19:22 ` H.J. Lu
2008-10-12 13:39 ` Mark Kettenis
2008-10-12 22:18 ` H.J. Lu
2008-10-28 14:11 ` H.J. Lu
2008-10-28 14:18 ` Daniel Jacobowitz
2008-10-28 17:29 ` Mark Kettenis
2008-10-29 7:41 ` H.J. Lu
2008-10-29 16:45 ` Mark Kettenis
2008-10-29 2:00 ` H.J. Lu
2008-10-29 2:16 ` Daniel Jacobowitz
2008-10-04 22:22 ` H.J. Lu
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=200810021026.m92AQMqC006955@brahms.sibelius.xs4all.nl \
--to=mark.kettenis@xs4all.nl \
--cc=dan@codesourcery.com \
--cc=gdb-patches@sourceware.org \
--cc=hjl.tools@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox