From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 745 invoked by alias); 4 Oct 2008 22:22:50 -0000 Received: (qmail 734 invoked by uid 22791); 4 Oct 2008 22:22:50 -0000 X-Spam-Check-By: sourceware.org Received: from ey-out-1920.google.com (HELO ey-out-1920.google.com) (74.125.78.148) by sourceware.org (qpsmtpd/0.31) with ESMTP; Sat, 04 Oct 2008 22:22:15 +0000 Received: by ey-out-1920.google.com with SMTP id 4so657946eyg.24 for ; Sat, 04 Oct 2008 15:22:11 -0700 (PDT) Received: by 10.210.16.10 with SMTP id 10mr1020070ebp.138.1223158931712; Sat, 04 Oct 2008 15:22:11 -0700 (PDT) Received: by 10.210.63.19 with HTTP; Sat, 4 Oct 2008 15:22:11 -0700 (PDT) Message-ID: <6dc9ffc80810041522t41bc2f8ao1e9da436c2978219@mail.gmail.com> Date: Sat, 04 Oct 2008 22:22:00 -0000 From: "H.J. Lu" To: "Mark Kettenis" Subject: Re: PATCH: Extend gdb remote protocol for AVX Cc: gdb-patches@sourceware.org, dan@codesourcery.com In-Reply-To: <200810042049.m94Kn3k8015088@brahms.sibelius.xs4all.nl> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20080918172728.GA12703@lucon.org> <200810021026.m92AQMqC006955@brahms.sibelius.xs4all.nl> <6dc9ffc80810020715o21079a0fn972cd30a94695f6c@mail.gmail.com> <200810042049.m94Kn3k8015088@brahms.sibelius.xs4all.nl> X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2008-10/txt/msg00119.txt.bz2 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. -- H.J.