From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3895 invoked by alias); 7 May 2005 16:19:48 -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 3396 invoked from network); 7 May 2005 16:19:39 -0000 Received: from unknown (HELO nevyn.them.org) (66.93.172.17) by sourceware.org with SMTP; 7 May 2005 16:19:39 -0000 Received: from drow by nevyn.them.org with local (Exim 4.50 #1 (Debian)) id 1DUS1j-00039E-4q for ; Sat, 07 May 2005 12:19:39 -0400 Date: Sat, 07 May 2005 16:19:00 -0000 From: Daniel Jacobowitz To: gdb@sourceware.org Subject: Re: RFC: Available registers as a target property Message-ID: <20050507161938.GA11730@nevyn.them.org> Mail-Followup-To: gdb@sourceware.org References: <20050506162029.GA30792@nevyn.them.org> <01c552ee$Blat.v2.4$e21a5dc0@zahav.net.il> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <01c552ee$Blat.v2.4$e21a5dc0@zahav.net.il> User-Agent: Mutt/1.5.8i X-SW-Source: 2005-05/txt/msg00092.txt.bz2 On Sat, May 07, 2005 at 01:22:57PM +0300, Eli Zaretskii wrote: > > 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. Yes indeed. When writing this I went to see if any of the parts of GDB I would be changing were in the manual; aside from the remote protocol bits, no hits. I do plan to write documentation to go along with these changes. > > 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? This solution is not limited to remote targets. The proposal does read that way, a bit - but that's because remote targets are the trickiest case, because remote targets enforce a certain cleanliness of interface. For instance, the strings I described included a target-protocol-specific number. For sim and native targets, there are other architecture hooks and bits of global state in GDB that the target can read and write. But the remote protocol has to encapsulate everything. The structure of the proposal is divided into two parts. One's a gdbarch hook, the other's a target hook. I've got implementations of the target hook for sim, remote, and native targets. For a native user-space GNU/Linux target, the implementation is fairly simple: partly based on predefined macros, i.e. how GDB was built, and partly based on trying ptrace operations on the new process and seeing if they work. > 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. Do you have any examples? I've got a feeling that there is additional information of this type, but I have no idea what it would be, or how GDB would represent or use it. The mechanism, in its current form, does allow for additional information - both string types start with a label, other labels could be added later. The only thing register-specific about it is the name of the hooks/packets. I did think a little bit about a more general name but couldn't come up with one. If you suggest a more general name I have no complaints about using it! > > 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. The reason I used strings was to maintain the separation between gdbarch vector and target vector - and to reuse the existing target_xfer_partial interface. Here's the dataflow: GDB calls the target vector to fetch the data, then parses the data, then passes the parsed data to the architecture vector. Thinking about it now, the parsing could be pushed down into the remote protocol implementation, and a C structure returned as a binary blob via target_read_partial. That's not a normal use of the interface, which currently returns target objects rather than internal GDB objects. It would work, and it would save constructing the string in the native and simulator cases (and core; I haven't been thinking about the core case, but an implementation there is probably possible too). Do you think that would be a better interface to choose? -- Daniel Jacobowitz CodeSourcery, LLC