From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 876 invoked by alias); 28 Feb 2010 22:23:00 -0000 Received: (qmail 856 invoked by uid 22791); 28 Feb 2010 22:22:59 -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 Feb 2010 22:22:53 +0000 Received: (qmail 6093 invoked from network); 28 Feb 2010 22:22:51 -0000 Received: from unknown (HELO caradoc.them.org) (dan@127.0.0.2) by mail.codesourcery.com with ESMTPA; 28 Feb 2010 22:22:51 -0000 Date: Sun, 28 Feb 2010 22:23:00 -0000 From: Daniel Jacobowitz To: "H.J. Lu" Cc: Mark Kettenis , gdb-patches@sourceware.org Subject: Re: PATCH: Enable x86 XML target descriptions Message-ID: <20100228222244.GA29360@caradoc.them.org> Mail-Followup-To: "H.J. Lu" , Mark Kettenis , gdb-patches@sourceware.org References: <20100210200303.GA19632@lucon.org> <20100218054312.GA9022@lucon.org> <20100218153402.GA27929@lucon.org> <20100218230135.GA17916@intel.com> <201002221342.o1MDgSZA029705@glazunov.sibelius.xs4all.nl> <6dc9ffc81002220617o1d348e68hc918d434118cadcb@mail.gmail.com> <201002282030.o1SKUe6V032104@glazunov.sibelius.xs4all.nl> <6dc9ffc81002281258s3289602cg8c06ceaed8bfe34a@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <6dc9ffc81002281258s3289602cg8c06ceaed8bfe34a@mail.gmail.com> User-Agent: Mutt/1.5.20 (2009-06-14) 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-02/txt/msg00709.txt.bz2 On Sun, Feb 28, 2010 at 12:58:40PM -0800, H.J. Lu wrote: > > Sorry, but I don't understand this.  How does checking a register in > > the target description care about the number of registers set in the > > gdbarch we're building? > > I copied it from ppc_linux_init_abi. Gdb won't work if I don't reserve > a register number for orig_rax: This part of the target descriptions infrastructure was designed to clean up a confusing aspect of some backends. If there are well-known registers - things that GDB has to treat specially for calling conventions, or read from to determine mode, anything like that - this lets us give them a fixed register number with a #define. Then, the register is concealed at runtime if it is not present on the target. If you want to have an orig_rax register with a constant register number, you need to bump up num_regs above that constant. So the key here is that he's not checking a register in the target. Independent of the target description supplied, he's bumping up the total "number of registers" to leave a gap for AMD64_LINUX_ORIG_RAX_REGNUM, because we said that AMD64_LINUX_ORIG_RAX_REGNUM was a valid register number (via the tdesc_numbered_register call). Is that clearer? > > Which seems wrong to me.  Both the core registers and the SSE > > registers are different in 64-bit mode.  But perhaps Daniel can shed > > some light on how these features are supposed to be used? There are two ways to do this. For Power, as HJ has pointed out, the features have size-independent names because they are mostly the same. There's still an r0, it's just 64-bit instead of 32-bit. Alternatively, you can define a 32-bit feature and a 64-bit feature with different names. IMO it does not make a lot of difference which version you choose. I would have chosen to give them separate names; there are too many differences, and I think it would simplify the code. But given how amd64 support is treated as an extension of GDB's i386 support, I can imagine that this approach makes sense. If we do stick to a single version, the x86 name seems better than i386. > The reason is i386_validate_tdesc_p is called by > i386_gdbarch_init after calling gdbarch_init_osabi, > which may set up a 64bit target description. If 64bit > target description has different feature name, it won't > find core and SSE registers. If you don't like "i386" > in the feature name, I can change it to x86. That's not a reason. You could just as easily make the code handle both variants. -- Daniel Jacobowitz CodeSourcery