From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25909 invoked by alias); 22 Feb 2010 14:41:56 -0000 Received: (qmail 25890 invoked by uid 22791); 22 Feb 2010 14:41: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; Mon, 22 Feb 2010 14:41:51 +0000 Received: (qmail 18306 invoked from network); 22 Feb 2010 14:41:50 -0000 Received: from unknown (HELO caradoc.them.org) (dan@127.0.0.2) by mail.codesourcery.com with ESMTPA; 22 Feb 2010 14:41:50 -0000 Date: Mon, 22 Feb 2010 14:41:00 -0000 From: Daniel Jacobowitz To: Mark Kettenis Cc: hjl.tools@gmail.com, gdb-patches@sourceware.org Subject: Re: PATCH: Enable x86 XML target descriptions Message-ID: <20100222144141.GA30100@caradoc.them.org> Mail-Followup-To: Mark Kettenis , hjl.tools@gmail.com, 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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201002221342.o1MDgSZA029705@glazunov.sibelius.xs4all.nl> 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/msg00532.txt.bz2 On Mon, Feb 22, 2010 at 02:42:28PM +0100, Mark Kettenis wrote: > > +/* Get Linux/x86 target description from running target. */ > > + > > +static const struct target_desc * > > +amd64_linux_read_description (struct target_ops *ops) > > +{ > > + if (gdbarch_ptr_bit (target_gdbarch) == 64) > > + return tdesc_amd64_linux; > > + else > > + return tdesc_i386_linux; > > +} > > + > > This made me wonder what happens if you attach to a process without > loading an executable first. Currently this works, since GDB can > figure out what executable belongs to the the process and load the > executable automatically. But I fear a chicken & egg problem here: > the gdbarch is derviced from the tdesc, but in order to determine the > tdesc you need a gdbarch. Yes, I'm not comfortable having this function respond based on the gdbarch. It's supposed to query the target. For instance, if you had a ptrace request that failed if the target was 32-bit, you could use that. If that's not possible, it probably shouldn't be implemented. > I didn't realize these functions would effectively be moved into > target-descriptions.c. That feels wrong. For avoidance of doubt, that's true of the flags functions and the builtin FP type; the vector type goes into the data files. The FP type there's no real way around. The flags types could (I think should) be transfered to the data files too - but it would require a new element in the XML files. I happen to have that patch sitting around somewhere... let me find it. -- Daniel Jacobowitz CodeSourcery