From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30145 invoked by alias); 28 Mar 2010 16:37:27 -0000 Received: (qmail 30135 invoked by uid 22791); 28 Mar 2010 16:37:26 -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 16:37:22 +0000 Received: by vws20 with SMTP id 20so5374106vws.0 for ; Sun, 28 Mar 2010 09:37:20 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.90.201 with HTTP; Sun, 28 Mar 2010 09:37:20 -0700 (PDT) In-Reply-To: <201003281717.00534.pedro@codesourcery.com> References: <20100304180219.GA10826@intel.com> <201003280855.44473.pedro@codesourcery.com> <6dc9ffc81003280756v230528a6q4392a729c78e0ce6@mail.gmail.com> <201003281717.00534.pedro@codesourcery.com> Date: Sun, 28 Mar 2010 16:37:00 -0000 Received: by 10.220.4.23 with SMTP id 23mr1678016vcp.71.1269794240150; Sun, 28 Mar 2010 09:37:20 -0700 (PDT) Message-ID: <6dc9ffc81003280937l5bde6ac1xd07573e633df8978@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/msg00945.txt.bz2 On Sun, Mar 28, 2010 at 9:17 AM, Pedro Alves wrote: > On Sunday 28 March 2010 15:56:17, H.J. Lu wrote: >> On Sun, Mar 28, 2010 at 12:55 AM, Pedro Alves w= rote: >> > 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 A= VX >> >> > test to the testsuite, if it's not too much trouble. =A0You're chec= king >> >> > for the "x86=3Dxml" feature in the target, but only calling the tar= get >> >> > 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= want >> >> > 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 qSu= pported >> > to the target before knowing the target's target description. =A0The t= arget >> > 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. > > I can't agree with that. =A0That's against the goal of having the target > fully self describe to GDB. =A0If that were true, then why would we > support target descriptions that describe the OSABI? > As I said and exampled above, you may not have a binary loaded in GDB > at all. =A0A design that assumes you have, can't be correct in all > supported cases. =A0GDB supports at least one x86 target that doesn't even > have a notion of executables, only shared libraries --- DICOS. =A0I would= n't > want users of a non-x86 GDB build that supported that target to have > to do "set architecture i386" or similar before connecting to be > able to access the full register set as described by the target. > > What are your worries with doing something as I suggested? > > [To clear up confusions, this is about target_gdbarch, not > current_target. =A0The current_target is always target > remote / remote.c] > I guess it may be OK to always "xmlRegisters+" to gdb stub and let each arch decide what to do. One problem may be 1. We add XXX support to gdb 7.2. 2. We enable XML support for XXX in gdb 7.3. What will happen when we run gdbserver fom gdb 7.3 against gdb 7.2? gdb will always send "xmlRegisters+" to gdb stub which will send back XML files. But gdb 7.2 doesn't support it. --=20 H.J.