From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6825 invoked by alias); 28 Mar 2010 07:55:56 -0000 Received: (qmail 6815 invoked by uid 22791); 28 Mar 2010 07:55:55 -0000 X-SWARE-Spam-Status: No, hits=-2.5 required=5.0 tests=AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from mail.codesourcery.com (HELO mail.codesourcery.com) (38.113.113.100) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Sun, 28 Mar 2010 07:55:50 +0000 Received: (qmail 16613 invoked from network); 28 Mar 2010 07:55:48 -0000 Received: from unknown (HELO orlando.localnet) (pedro@127.0.0.2) by mail.codesourcery.com with ESMTPA; 28 Mar 2010 07:55:48 -0000 From: Pedro Alves To: gdb-patches@sourceware.org Subject: Re: PATCH: 6/6 [2nd try]: Add AVX support (gdbserver changes) Date: Sun, 28 Mar 2010 07:55:00 -0000 User-Agent: KMail/1.12.2 (Linux/2.6.31-20-generic; KDE/4.3.2; x86_64; ; ) Cc: "H.J. Lu" References: <20100304180219.GA10826@intel.com> <20100327160705.GB16019@caradoc.them.org> <6dc9ffc81003271811t5be04ef9yf888edbce6d85236@mail.gmail.com> In-Reply-To: <6dc9ffc81003271811t5be04ef9yf888edbce6d85236@mail.gmail.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201003280855.44473.pedro@codesourcery.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: 2010-03/txt/msg00939.txt.bz2 On Sunday 28 March 2010 02:11:31, H.J. Lu wrote: > > I guess you haven't tested this one :-) You may want to add an AVX > > test to the testsuite, if it's not too much trouble. You're checking > > for the "x86=xml" feature in the target, but only calling the target > > method for "x86:xstate=...". I 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. Newer versions, which do > > support XML, will use whatever the target supplies. So, you only want > > the target to supply the registers via XML if GDB will understand > > them. Is 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? That 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. There's a bootstrapping problem here. GDB sends qSupported to the target before knowing the target's target description. The target 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. That'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=all GDB build, and you simply do: $ gdb (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=xml" feature (the target_gdbarch would be set to something not-x86 early in the connection, at the point gdbarch_qsupported it called). With 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=xml" or something similar to the target unconditionally of whatever target_gdbarch is before having fetched the target description. What do you guys think? Did I miss this being discussed? -- Pedro Alves