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

[Daniel Jacobowitz <drow@xxxxxxxxx>]

On Thu, Jun 01, 2006 at 03:17:19PM -0700, Spear, Aaron wrote:
> Your concerns listed below are all quite valid of course.  SPIRIT is
> missing things we need (e.g. native registers in a core) and has a lot
> of things we have no use for right now.  The SPIRIT community seems
> willing to extend their standard for what we need, so the potential is
> there.  The issue is refining the vision for what we need, and then
> creating tools that can use the information.

And persuading all the silicon vendors who supply these files to you to
add the additional information needed by the debugger, which likely
they don't have any other need for.  Thus, it's likely to be untested
or lightly tested, and you're back to the abused intern scenario.  Or
do I misunderstand?  Adding additional information to the
vendor-supplied files, after the fact, would be a management nightmare.

> How does the debugger back end use the SPIRIT info?
> 
> The point you bring up is valid, and we have not addressed it yet.  If
> the parsing of these target descriptions (be it in SPIRIT XML or
> whatever) is done in Java as a DSDP component, then how can the debugger
> back end make use of it?  This is applicable to more than just GDB,
> because pretty much every company involved here has much of their
> commercial debugger back end in some separate native executable or
> shared lib/dll or something else that is not Java.  What any given
> implementation will have to do will likely be different.
> 
> My company has a debugger architecture that has a Java implementation of
> Eclipse debug model + native debug engine in via JNI.  In order for us
> to use these interfaces, we will likely have to create an API whereby
> the DSDP/Java target descriptions can be pushed from the Eclipse front
> end into the debugger.  I don't see a choice as I really don't want to
> write SPIRIT parsers more than once.  I am guessing that you would want
> to do the same thing with GDB if possible.  
> 
> I would like to hear others thoughts on this.

This is a matter of models and goals.  What you've described sounds
good to me when these two conditions both hold:

(1) Your debugger is designed to specifically support Eclipse.

(2) Your debugger is "thin", i.e. focused on low level operations with
    more sophisticated issues managed by a GUI front end.

The reasoning for (1) is that if the target descriptions are parsed on
the Eclipse side of the connection, and pushed from there to the
debugger side, then the debugger has become dependent on Eclipse for
full functionality.  There are a multitude of back ends and a multitude
of front ends in the world, and some debuggers ("back ends" in this
context) need to support more than one front end.

The reasoning for (2) is that what the debugger can do with the target
is limited by the information you give it.  The simplest example is for
GDB's console window; not only does GDB support a text interface for
standalone usage, many people are so comfortable with it that several
GUI debuggers built on top of the MI protocol layer also provide direct
access to the GDB CLI.  Just about anything that is interesting to
Eclipse is also interesting to the CLI.

I think any "thick" debugger is going to need to process the same
data files that Eclipse is interested in - whatever format they may
turn out to have.

One element of the GDB plan is to fetch descriptions directly from the
target system, which for JTAG targets usually means over TCP from the
intermediate stub converting JTAG to the GDB remote protocol.  This
allows GDB to reliably load the correct configuration on connection.
Therefore, I planned to offer the complete XML data to the MI consumer
through new (as yet undecided) MI commands.  The XML structures
involved are kept simple, with the expectation that both GDB and its
front end will need to parse them to some degree.

> One other piece that is missing from my perspective is the mapping
> between the representation used in the "front end" for a native register
> in a given core, and the representation that must be used in the
> debugger back end.  In our commercial debugger we address this with two
> sets of XML files.  One set describes the targets:
> boards/cores/registers in the core/memory maps/memory mapped registers
> etc (and is analogous to SPIRIT files), and then another XML file
> contains a connection specific mapping between the string representation
> of the register id used everywhere else in the debugger, and whatever
> the back end uses to access registers.  For a GDBServer connection for a
> PPC target for instance it looks like this:
> 
> <register from="R0" to="0" />

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.

However, while I've sketched the issues, I stopped before pursuing
them.  The current GDB support is non-hierarchical.

If you're interested in concrete details, they're here:
  http://sourceware.org/ml/gdb/2006-03/msg00197.html

By the way, while I look forward to a fruitful conversation here,
I intend to go ahead with that proposal.  If it turns out that
something else would be more useful, e.g. SPIRIT, we can either add
that to GDB or replace this; as you mentioned, I don't want to draw
out the design to a point where nothing gets checked in.

-- 
Daniel Jacobowitz
CodeSourcery