This is the mail archive of the gdb@sources.redhat.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: RFC: Available registers as a target property


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]