Re: RFC: Available registers as a target property

["Eli Zaretskii" <eliz@gnu.org>]

> Date: Fri, 6 May 2005 12:20:29 -0400
> From: Daniel Jacobowitz <drow@false.org>
> 
> 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.