Re: [dsdp-dd-dev] Debug model and GDB?

[Daniel Jacobowitz <drow@xxxxxxxxx>]

I'm happy.  When I first encountered the description of what you were
doing, it seemed that we were coming from very different directions,
but a little communication is showing that we're really moving the same
way!

On Fri, Jun 02, 2006 at 07:51:32AM -0700, Spear, Aaron wrote:
> Yes, point taken.  I know exactly where you are coming from, and I have
> the same issue.  Our debugger can run stand alone as a command line
> client optionally as well, and indeed people who want to do heavy duty
> regression testing of hardware by scripting the debugger want and need
> this. There is also of course the camp of customers that trumpets "I
> don't need no dang GUI debugger, why in my day..."  (of course they are
> mostly using GDB ;-)
> 
> So I am torn as well on this issue.  There is certainly merit to what I
> hear you at least implying, that we would be better served to adopt a
> small controllable subset of XML for the target description format.  If
> we did do that, then we could also push the SPIRIT standard to include
> additional info that we need and rely on XSLT transformations or the
> like to extract/translate the format to what we use.  Then different
> parsing code can be written around the small standard.  An EPL licensed
> open source C/C++ library that can be used in GDB or other commercial
> debuggers, as well as a Java one.

Right.  My current plan was, roughly, to ignore SPIRIT until someone
approached the GDB developers with a motivation to support it.  If that
happened, then the implication would be that the SPIRIT descriptions
had enough information for GDB to function; then postprocess them into
something similar to GDB's native representation.

I thought I'd seen you say that relying on transformations of the
SPIRIT data had been a major source of problems, though?

[For various GNU-y reasons, GDB could not use an EPL licensed library
directly.  However, a separate tool could use that library to perform
the transformations, and GDB could have its own parser for the native
format.]

> Note that this is consistent with what DSDP is currently doing.  I am
> not sure if you are aware that we have a target management sub-project
> of DSDP which has a "Remote System Explorer" (RSE).  RSE is able to
> connect to arbitrary systems and expose services on them.  In some cases
> if it is a full blown OS on the other side, you can get services like
> opening a shell, ftp, or launching a debugger.  In theory we can also
> have GDBServer connections to a remote machine listed, and you could
> right click on the connection and launch the debugger to connect to it.
> In fact it might have already been done with the CDT, I am not sure
> (anyone?).
> 
> These targets that show up in RSE providing/serving interfaces for
> target info is a goal that we have.  We are just trying to come up with
> a way to have a standard XML schema for this target info, so whether the
> parsing of this is done on the remote side, or on the host side, it
> doesn't matter.

OK.  I had encountered a description of RSE up at the remote connection
layer, but I hadn't realized you wanted to extend it all the way down
to the target descriptions.

> > This isn't something I've thought much about, but I don't 
> > think the centralized use of short names is advisable.  I 
> > wanted the descriptions I wrote to be robust against the 
> > naming choices of third party providers, and the system 
> > layout - e.g. a target with more than one exactly identical 
> > arithmetic coprocessor.  A certain amount of hierarchy here 
> > is unavoidable.
> 
> I think you misunderstand what I was saying.  This is not a centralized
> "short notation", but rather a data driven translation between a
> representation that the user will think about when using the debugger
> ("R0") and a representation that must be used by the debugger internally
> when it goes to send a command to GDBServer or other connection to read
> a register.  As I understand it, in GDBServer the protocol is "P0" or
> something where the second part is a register index to read a given
> register.  What does the index mean?  Of course different things when
> connecting to different targets.  Which is why it is compelling to have
> it be data driven instead of hard coded into a binary.

I think we've got two separate concepts tangled up here.

On the issue of short names, you had a map from "R0" to "0".  There's a
question of "what does R0 refer to?".  As long as you only have one
device in your system that decided that R0 was a good name for a
register, you're in good shape.  But if some cretinous peripheral
decides to reuse the core's naming, all of a sudden it's not clear what
you mean - or what the user means when they type "print $r0".

On the more interesting issue of protocol numbers, I didn't make the
register identity and protocol number completely independent in the GDB
native representation, but I did separate them.  Here's how it works.
First we have a "feature", corresponding in this case to the ARM VFPv2
coprocessor:

<?xml version="1.0"?>
<!DOCTYPE feature SYSTEM "gdb-target.dtd">
<feature name="org.gnu.gdb.arm.vfp">
  <reg name="fpsid" bitsize="32" type="int" group="float"/>
  <reg name="fpscr" bitsize="32" type="int" group="float"/>
  <reg name="fpexc" bitsize="32" type="int" regnum="8" group="float"/>

  <reg name="s0" bitsize="32" type="float" regnum="16"/>

  ...
</feature>

Then we have a target description, which ties all these components
together:

<?xml version="1.0"?>
<!DOCTYPE target SYSTEM "gdb-target.dtd">
<target>
  <xi:include href="arm-core.xml"/>
  <xi:include href="arm-vfp.xml"/>
  <feature-set>
    <feature-ref name="org.gnu.gdb.arm.core" base-regnum="0"/>
    <feature-ref name="org.gnu.gdb.arm.vfp" base-regnum="64"/>
  </feature-set>
</target>

The register numbers (0 for fpsid, 16 for s0, et cetera) get rescaled
at the point of instantiation.

So, OK, if you have a single integrated device (e.g. a SoC) with a big
description, and you want to be able to connect multiple different
debug widgets to it, and you don't have control over the numberings
used by those widgets, then you might be in trouble.  In reality, I
don't think that's an important scenario, in the model in which the
debug widget pushes the description to the connected debugger.

I've got one set of legacy widgets to accomodate (older versions of GDB
and the undocumented register numbers used by the GDB g/G/p/P packets).
But that's mostly a convenience factor; if necessary, I could make the
stub support two numberings, and switch if the debugger asked for a
target description.

-- 
Daniel Jacobowitz
CodeSourcery