From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27603 invoked by alias); 28 Mar 2010 14:56:24 -0000 Received: (qmail 27594 invoked by uid 22791); 28 Mar 2010 14:56:23 -0000 X-SWARE-Spam-Status: No, hits=-1.8 required=5.0 tests=AWL,BAYES_00,SARE_MSGID_LONG40 X-Spam-Check-By: sourceware.org Received: from mail-vw0-f41.google.com (HELO mail-vw0-f41.google.com) (209.85.212.41) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Sun, 28 Mar 2010 14:56:19 +0000 Received: by vws20 with SMTP id 20so5350573vws.0 for ; Sun, 28 Mar 2010 07:56:17 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.90.201 with HTTP; Sun, 28 Mar 2010 07:56:17 -0700 (PDT) In-Reply-To: <201003280855.44473.pedro@codesourcery.com> References: <20100304180219.GA10826@intel.com> <20100327160705.GB16019@caradoc.them.org> <6dc9ffc81003271811t5be04ef9yf888edbce6d85236@mail.gmail.com> <201003280855.44473.pedro@codesourcery.com> Date: Sun, 28 Mar 2010 14:56:00 -0000 Received: by 10.220.124.214 with SMTP id v22mr2115886vcr.221.1269788177231; Sun, 28 Mar 2010 07:56:17 -0700 (PDT) Message-ID: <6dc9ffc81003280756v230528a6q4392a729c78e0ce6@mail.gmail.com> Subject: Re: PATCH: 6/6 [2nd try]: Add AVX support (gdbserver changes) From: "H.J. Lu" To: Pedro Alves Cc: gdb-patches@sourceware.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 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: 2010-03/txt/msg00942.txt.bz2 On Sun, Mar 28, 2010 at 12:55 AM, Pedro Alves wrot= e: > On Sunday 28 March 2010 02:11:31, H.J. Lu wrote: >> > I guess you haven't tested this one :-) =A0You may want to add an AVX >> > test to the testsuite, if it's not too much trouble. =A0You're checking >> > for the "x86=3Dxml" feature in the target, but only calling the target >> > method for "x86:xstate=3D...". =A0I don't see how it could work. >> > >> > The problem we're solving by modifying qSupported is that older >> > versions of GDB, which do not support XML registers at all, assume >> > a specific layout for the g/G packet. =A0Newer versions, which do >> > support XML, will use whatever the target supplies. =A0So, you only wa= nt >> > the target to supply the registers via XML if GDB will understand >> > them. =A0Is that accurate? >> >> Yes, >> >> > If that's the scope of the problem, then how about we handle >> > this in a way we can reuse for other targets? =A0That doesn't have >> > to change the implementation; just rename the feature to >> > "xmlRegisters+". >> >> I will make the change. > > This (and the gdbarch_qsupported mechanism) worries me multi-arch > design wise. =A0There's a bootstrapping problem here. =A0GDB sends qSuppo= rted > to the target before knowing the target's target description. =A0The targ= et > sends the target description based on qSupported. > As is, things only work correctly, when GDB already somehow knows the > arch is some sort of x86 _before_ connecting to the target. =A0That's > usually true if you give GDB a binary, but may not be true in some > use cases. > > As a matter of example, if you have, say, a PPC --enable-targets=3Dall > GDB build, and you simply do: > > =A0$ gdb > =A0(gdb) tar rem :9999 > > to connect to a x86 linux gdbserver, then, the x86 target will not > be sending the registers target description, because GDB wouldn't > be sending the "x86=3Dxml" feature (the target_gdbarch would be > set to something not-x86 early in the connection, at the point > gdbarch_qsupported it called). =A0With the "xmlRegisters+" change, > it would be slightly even worse, as GDB would be sending a generic > "xmlRegisters+", meaning "Hello target, I understand xml register > descriptions for your arch", but, at a point when it may be > mistaken what is the target's arch, and the target would > have no way of knowing that. > > It seems to me that GDB should be sending "x86=3Dxml" or something > similar to the target unconditionally of whatever target_gdbarch is > before having fetched the target description. > I think current_target should be set to something sensible before sending qSupported. It should match arch and OSABI of the executable. --=20 H.J.