[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
RE: [dsdp-dd-dev] Debug model and GDB?
|
Hi Daniel,
Welcome! I think that there is certainly a difference in direction
between SPIRIT and the needs of a debugger. This makes sense
considering that SPIRIT's original intent was to facilitate connection
of IP blocks within an SoC. What is inside of the IP block doesn't so
much matter to the SoC tools, just interfaces like buses. To a debugger
on the other hand we must know what is inside of the block, e.g. what
native registers are inside of a given core, not just memory mapped
stuff.
In the various DSDP meetings there were vendors representing a lot of
different embedded commercial debuggers, and all of us were lamenting
the pain of maintaining the myriads of proprietary target description
files we use. Inevitably they are mostly untested due to the sheer
volume of what had to be done, and the daunting task of testing them
all. When we looked at SPIRIT it seemed like it held the best promise
of actually getting content that was accurate and complete. Getting the
actual files from the silicon vendor that were used in creation of the
SoC would go much further to guarantee this. Certainly better quality
than we got out of the abused interns mindlessly transcribing data
books.
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.
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.
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" />
...
<register from="MSR" to="33" />
<register from="CR" to="34" />
This is yet another piece that we have not ironed out, but it is very
connection specific, so perhaps it is an implementation detail for
individual vendors to worry about. Other people have brought up the
rest of data driven stuff we could do as well: data driven
disassemblers, instruction simulators, why not have the whole ISA
described in the XML? If we go there now, we will never get anything
done, so we need to baby step...
cheers,
Aaron
--
Aaron Spear
Debug Tools Architect/Staff Engineer
Mentor Graphics
-----Original Message-----
From: dsdp-dd-dev-bounces@xxxxxxxxxxx
[mailto:dsdp-dd-dev-bounces@xxxxxxxxxxx] On Behalf Of Daniel Jacobowitz
Sent: Thursday, June 01, 2006 10:50 AM
To: dsdp-dd-dev@xxxxxxxxxxx
Subject: [dsdp-dd-dev] Debug model and GDB?
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
_______________________________________________
dsdp-dd-dev mailing list
dsdp-dd-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/dsdp-dd-dev
