From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10126 invoked by alias); 12 Oct 2008 22:18:52 -0000 Received: (qmail 10117 invoked by uid 22791); 12 Oct 2008 22:18:52 -0000 X-Spam-Check-By: sourceware.org Received: from nf-out-0910.google.com (HELO nf-out-0910.google.com) (64.233.182.185) by sourceware.org (qpsmtpd/0.31) with ESMTP; Sun, 12 Oct 2008 22:17:52 +0000 Received: by nf-out-0910.google.com with SMTP id h3so669553nfh.48 for ; Sun, 12 Oct 2008 15:17:49 -0700 (PDT) Received: by 10.210.67.4 with SMTP id p4mr4436735eba.174.1223849868185; Sun, 12 Oct 2008 15:17:48 -0700 (PDT) Received: by 10.210.63.19 with HTTP; Sun, 12 Oct 2008 15:17:48 -0700 (PDT) Message-ID: <6dc9ffc80810121517n1581323cl21808a5f99cce13d@mail.gmail.com> Date: Sun, 12 Oct 2008 22:18:00 -0000 From: "H.J. Lu" To: "Mark Kettenis" Subject: Re: PATCH: Extend gdb remote protocol for AVX Cc: gdb-patches@sourceware.org In-Reply-To: <200810121337.m9CDbu7Y031268@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> <20081004221325.GA6856@caradoc.them.org> <6dc9ffc80810050737r56b0d044vcf8e8f1368d2d03d@mail.gmail.com> <200810062135.m96LZI0H016325@brahms.sibelius.xs4all.nl> <6dc9ffc80810071221r10439dd2m886637a1dc7327ab@mail.gmail.com> <200810121337.m9CDbu7Y031268@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/msg00334.txt.bz2 On Sun, Oct 12, 2008 at 6:37 AM, Mark Kettenis wrote: >> Gcc 4.4 supports AVX. Gcc uses the same register number internally >> for xmm0 and ymm0. It has no problems with register allocator. > > I guess that makes sense. Otherwise the register allocator might > think it can use xmm0 independently from ymm0. > >> > 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. >> > >> >> The AVX x86-64 psABI extension is at >> >> http://gcc.gnu.org/ml/gcc/2008-06/msg00408.html >> >> The ia32 psABI extension is similar to SSE. The only difference is >> __m256 requires 32byte alignment, instead of 16btye. > > And it doesn't mention the DWARF debug register mapping. That's sad. > >> I removed AVX register map: >> >> http://sourceware.org/ml/binutils/2008-08/msg00010.html >> >> since xmm/ymm registers are all caller-saved and there are >> no xmm/ymm registers in unwind info. > > That's a mistake. Unwind info for signal handlers should mention > xmm/ymm registers. Although I'm not sure how one would express the > xsave layout in DWARF. I removed ymm register map. But I reserved those ranges for future ymm register use. If it turns out that we really need them, we can reenable the map. So far I haven't found xmm register map is used anywhere, including signal handler. > >> For debug info, we can tell ymm from xmm with data size. > > But what should "info address" display for a variable stored in a %ymm > register? If we can't distinguish between the two, we'll probably end > up printing %xmm. > We can treat variables in xmm/ymm the same way as variables in al/ax/eax/rax. Thanks. -- H.J.