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

[Doug Schaefer <DSchaefer@xxxxxxx>]

That's a great point Aaron. I think there are big enough players in Eclipse
now that we can throw our weight around a little. It's all for the good of
our mutual customers (i.e. the tool and the silicon vendors).

Doug Schaefer, QNX Software Systems
Eclipse CDT Project Lead, Tools PMC member
http://cdtdoug.blogspot.com
 

-----Original Message-----
From: dsdp-dd-dev-bounces@xxxxxxxxxxx
[mailto:dsdp-dd-dev-bounces@xxxxxxxxxxx] On Behalf Of Spear, Aaron
Sent: Friday, June 02, 2006 10:52 AM
To: Device Debugging developer discussions
Subject: RE: [dsdp-dd-dev] Debug model and GDB?

> Daniel Jacobowitz wrote:
> 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.

Yes, this is still a problem.  However, I am hoping that peer pressure
can convince them that they should provide the extra info.  At the end
of the day, most of the silicon companies want to sell chips, and in
order to do that they want a solid base of tools that support their
chips, and a best in class debug/development experience.  If by abusing
the intern on THEIR END they can thus enable a very nice debug
experience with many debuggers, why would they not do it?  If enough
debugger vendors support it, it would be the first thing approaching a
standard for this, so perhaps we can lean on them...

> 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.

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.
 
> 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.

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.

> 
> > 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.

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.
 
regards,
Aaron 

--
Aaron Spear               aaron_spear@xxxxxxxxxx 
Debug Tools Architect/Staff Engineer
Mentor Graphics



_______________________________________________
dsdp-dd-dev mailing list
dsdp-dd-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/dsdp-dd-dev