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

[Daniel Jacobowitz <drow@xxxxxxxxx>]

Hi everybody,

A colleague of mine referred me to the DSDP web site today, and I've
just joined the list.  I'm really not sure how I never heard about this
effort before.  I'm still reading my way through the archives and web
site, so please forgive me if I'm asking silly questions.  My
background is entirely with GDB, not Eclipse, which may help to explain
some of those questions.

CodeSourcery realized (about two years ago) that GDB needed to have
some support for debugging customized targets.  We, and I in
particular, have been working on that.  We've shipped a version of GDB
which fetches XML description files from remote targets and supports
loading additional registers from the descriptions.  Not much besides
registers has been implemented at this point, and the implementation
hasn't been merged to the main GDB development line yet, but it is
entirely functional.

I'm a bit surprised that there's not a single overlap between this list
and the GDB list where that was originally discussed.  I've gotten the
impression that some of the folks here do plan to have GDB be the
underlying debugger for communication with their devices.

How do you expect the target descriptions which you're talking about
(SPIRIT based?) to interact with the underlying debugger?  What would
it get from them, what would it just pass through to Eclipse?  Or is
the long term plan to bypass a traditional MI-protocol debugger
entirely, in favor of additional Eclipse components?

By the way, we considered using SPIRIT directly.  But:

  - It didn't seem to cover the information we needed, indicating
    a difference in direction.
  - It may not have had what we needed, but it did have a huge amount
    of other information that we didn't, leading to a very high
    complexity requirement for the initial implementation.
  - The SPIRIT consortium documentation had various IP-related terms
    which I felt could be a problem for GNU software.

All of these are probably solvable problems, given sufficient
motivation in favor of using SPIRIT.  But we felt it wiser to use
an unrelated XML format which covered our needs and was in our complete
control.

-- 
Daniel Jacobowitz
CodeSourcery