From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9110 invoked by alias); 28 Oct 2008 05:59:40 -0000 Received: (qmail 9098 invoked by uid 22791); 28 Oct 2008 05:59:39 -0000 X-Spam-Check-By: sourceware.org Received: from ik-out-1112.google.com (HELO ik-out-1112.google.com) (66.249.90.177) by sourceware.org (qpsmtpd/0.31) with ESMTP; Tue, 28 Oct 2008 05:58:40 +0000 Received: by ik-out-1112.google.com with SMTP id c28so639633ika.0 for ; Mon, 27 Oct 2008 22:58:36 -0700 (PDT) Received: by 10.210.45.17 with SMTP id s17mr7798170ebs.168.1225173516147; Mon, 27 Oct 2008 22:58:36 -0700 (PDT) Received: by 10.210.66.15 with HTTP; Mon, 27 Oct 2008 22:58:36 -0700 (PDT) Message-ID: <6dc9ffc80810272258m60f6d1c6w54b012ee90346b21@mail.gmail.com> Date: Tue, 28 Oct 2008 14:11: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: <6dc9ffc80810121517n1581323cl21808a5f99cce13d@mail.gmail.com> 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> <6dc9ffc80810121517n1581323cl21808a5f99cce13d@mail.gmail.com> 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/msg00673.txt.bz2 On Sun, Oct 12, 2008 at 3:17 PM, H.J. Lu wrote: > 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. > Are there any objections to my AVX patch? Thanks. -- H.J.