Re: [cdt-debug-dev] JTAG (was: The fate of the current GDB support in CD

[Daniel Jacobowitz <drow@xxxxxxxxx>]

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