From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30183 invoked by alias); 6 Oct 2008 21:35:58 -0000 Received: (qmail 30173 invoked by uid 22791); 6 Oct 2008 21:35:58 -0000 X-Spam-Check-By: sourceware.org Received: from sibelius.xs4all.nl (HELO sibelius.xs4all.nl) (82.92.89.47) by sourceware.org (qpsmtpd/0.31) with ESMTP; Mon, 06 Oct 2008 21:35:23 +0000 Received: from brahms.sibelius.xs4all.nl (kettenis@localhost.sibelius.xs4all.nl [127.0.0.1]) by brahms.sibelius.xs4all.nl (8.14.3/8.14.3) with ESMTP id m96LZIMM021445; Mon, 6 Oct 2008 23:35:18 +0200 (CEST) Received: (from kettenis@localhost) by brahms.sibelius.xs4all.nl (8.14.3/8.14.3/Submit) id m96LZI0H016325; Mon, 6 Oct 2008 23:35:18 +0200 (CEST) Date: Mon, 06 Oct 2008 21:35:00 -0000 Message-Id: <200810062135.m96LZI0H016325@brahms.sibelius.xs4all.nl> From: Mark Kettenis To: hjl.tools@gmail.com CC: hjl.tools@gmail.com, gdb-patches@sourceware.org In-reply-to: <6dc9ffc80810050737r56b0d044vcf8e8f1368d2d03d@mail.gmail.com> (hjl.tools@gmail.com) Subject: Re: PATCH: Extend gdb remote protocol for AVX References: <20080918172728.GA12703@lucon.org> <200810021026.m92AQMqC006955@brahms.sibelius.xs4all.nl> <6dc9ffc80810020715o21079a0fn972cd30a94695f6c@mail.gmail.com> <200810042049.m94Kn3k8015088@brahms.sibelius.xs4all.nl> <20081004221325.GA6856@caradoc.them.org> <6dc9ffc80810050737r56b0d044vcf8e8f1368d2d03d@mail.gmail.com> 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/msg00174.txt.bz2 > Date: Sun, 5 Oct 2008 07:37:13 -0700 > From: "H.J. Lu" > > On Sat, Oct 4, 2008 at 3:13 PM, Daniel Jacobowitz wrote: > >> 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). > > > > One way would be to transfer the xmm registers and then the remaining > > bits as unnamed registers; another, probably easier way would be to > > use an architecture specification or an actual register description to > > transfer just the ymm registers and let GDB know about that fact, so > > it can synthesize the xmm registers. > > > > (I don't remember the original patch, that may be what you're talking > > about already.) > > > > My proposal transfers the whole 256bit registers. We can display > xmm registers as the lower 128bit ymm registers if we can > display al/ax/eax. That certainly is a possibility, but if it is the right choice depends on quite a bit more things that just ease of implementation of the remote protocol. An important thing to check is what register numbers compilers (and GCC in particular) use for these registers. Are there compilers that already implement support for these new AVX instructions? We really should make sure the DWARF register number mapping in the AMD64 psABI gets updated for these new registers. Given the way the current mapping us defined for %stN and %mmN, it probably makes sense to give %ymmN their own numbers.