From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21110 invoked by alias); 7 May 2005 10:25:36 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 21010 invoked from network); 7 May 2005 10:25:28 -0000 Received: from unknown (HELO legolas.inter.net.il) (192.114.186.24) by sourceware.org with SMTP; 7 May 2005 10:25:28 -0000 Received: from zaretski (IGLD-80-230-69-180.inter.net.il [80.230.69.180]) by legolas.inter.net.il (MOS 3.5.6-GR) with ESMTP id EHV12319 (AUTH halo1); Sat, 7 May 2005 13:25:27 +0300 (IDT) Date: Sat, 07 May 2005 10:25:00 -0000 From: "Eli Zaretskii" To: gdb@sourceware.org Message-ID: <01c552ee$Blat.v2.4$e21a5dc0@zahav.net.il> Content-Transfer-Encoding: 7BIT Content-Type: text/plain; charset=ISO-8859-1 In-reply-to: <20050506162029.GA30792@nevyn.them.org> (message from Daniel Jacobowitz on Fri, 6 May 2005 12:20:29 -0400) Subject: Re: RFC: Available registers as a target property Reply-to: Eli Zaretskii References: <20050506162029.GA30792@nevyn.them.org> X-SW-Source: 2005-05/txt/msg00089.txt.bz2 > Date: Fri, 6 May 2005 12:20:29 -0400 > From: Daniel Jacobowitz > > Please bear with me; this is so long-winded I felt the need to give it > section titles. I'm interested in any and all comments about the problem or > about my solution. I hope to start implementing within a couple of weeks. Thanks. > Today, the contents of the register cache and the layout of GDB's regnum > space are determined by the gdbarch. There are several hooks for this, > primarily these three: > > num_regs > register_name > register_type > > The gdbarch determines what raw registers are available. But this isn't a > perfect match with what raw registers are _really_ available, because the > gdbarch only has the clues we use to select a gdbarch available: things like > byte order and BFD machine number. At best, those tell us what registers > the binary we're debugging requires. The runtime set of registers we can > see are a property of the target, not of the gdbarch. BTW, I'd be thrilled to see these issues spelled out and explained in gdbint.texinfo. Right now, that part of the internals manual is a mess of outdated information and incomplete or non-existent description of new features. If you, or someone else, could offer even unstructured text, I could use that to start working on the manual. I think it's absurd that such a central part of GDB's internals is not documented in any reasonable way. > After connecting to a target, GDB checks the current gdbarch for a new > method, gdbarch_set_available_registers. If the architecture does not > provide this method, the rest of the process is skipped. > > GDB then reads the TARGET_OBJECT_AVAILABLE_REGISTERS object from the target, > parses it, and hands it to the gdbarch for final processing. This means > that the object must have a target-independent format, although it will > have target-dependent content also. > > The target calls gdbarch_update_p with an appropriately filled in argument, > which calls its gdbarch_init routine, which can then do the real work of > updating gdbarch_num_regs et cetera. This means that the gdbarch_init > routine must correctly handle filling in defaults based on the last > architecture. That code is a bit fragile because it's undertested; I > recently updated ARM to do this robustly. FWIW, I think it's a good idea to add this to GDB. However, I'm puzzled why your proposal sounds limited to remote targets (the explicit references to the remote protocol and the syntax of the data objects seem to suggest that). Isn't this problem relevant to native debugging as well? If it is, then why not describe the solution in more general terms, so that they will be appropriate for native targets? Also, is it indeed a fact that information about registers is the only issue GDB has to deal with in such situations? Maybe we need to think about a more general mechanism, even if for now we only pass register-related information. > I created a gdbarch hook which returns a string describing the capabilities You consistently talk about strings as representing the target capabilities. Why not design a C data structure instead? A string is an inefficient way of passing information around.