[dsdp-dd-dev] RE: [cdt-debug-dev] JTAG (was: The fate of the current GDB

[Doug Schaefer <DSchaefer@xxxxxxx>]

Thanks, Daniel, I think you are right on the mark. Certainly I wouldn't want
to see users have to enter the magic commands for every launch config. And I
am thinking of initializing the memory subsystems and downloading images and
configuring symbols addresses for my work. Having a standard way to do this
and hide the details would certainly be a huge benefit for all users/vendors
trying to do this with the CDT.

So going forward, would you be interested working together on a contribution
to Eclipse for JTAG/gdb support? Or have you already started down this path?

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

-----Original Message-----
From: cdt-debug-dev-bounces@xxxxxxxxxxx
[mailto:cdt-debug-dev-bounces@xxxxxxxxxxx] On Behalf Of Daniel Jacobowitz
Sent: Friday, September 01, 2006 10:31 AM
To: cdt-debug-dev@xxxxxxxxxxx
Subject: Re: [cdt-debug-dev] JTAG (was: The fate of the current GDB support
in CDT)

On Fri, Sep 01, 2006 at 10:17:27AM -0400, Doug Schaefer wrote:
> Well, I'm still pretty early in this. I've just started learning all the
> things you can do with JTAG (I've been away too long from embedded
> development, these things are wicked cool!).
> 
> My first thoughts is that you generally need to send down device and
> platform specific 'monitor' commands to set up the remote target for
debug.
> My first thoughts is to do something similar to Oyvind's work where the
user
> can specify a list of gdb commands that are run after hooking up to the
> 'target remote' and before setting breakpoints and continuing. The CDT
> currently has gdbserver support hidden which I'd like to expose at a
higher
> level and add this extra command support to that facility.
> 
> That's my early thinking. I'd be interested in hearing how others hook up
> JTAG devices to the CDT.

With a small but important philosophical difference.  Your approach
sounds good if you take both GDB and the debug stub as invariants, and
try to solve any remaining problems in CDT, but I don't think that's
the right level for it - this is partly affected by (A) being a GNU
tools developer, and (B) liking to also use GDB without frontends, of
course.

For our JTAG stubs at CodeSourcery, we're of the opinion that the user
shouldn't have to do anything to set the target up for debugging.  We
have just started writing XML configuration file parsers for JTAG stubs
(I did another one yesterday, in fact).  If the target needs to be
configured for debugging, then you put appropriate initialization
commands in the configuration file.  Then, when you start the stub
and connect using GDB, everything Just Works.

A logical extension of this, if the advantage you want is to be able to
use Eclipse to control the board configuration, would be to generate
the configuration file :-)

I'm talking about things like configuring SDRAM controllers; I'm not
sure if you mean the same sort of configuration, or something
different.  It is probably worth coping with debugging agents that
require additional monitor commands; I just don't think that writing
new ones serves users well.

-- 
Daniel Jacobowitz
CodeSourcery
_______________________________________________
cdt-debug-dev mailing list
cdt-debug-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cdt-debug-dev