gdb and jtag

[David Brown]

> >
> > That's certainly another way to go.
> > Question: Why choose one over the other?
> >
> > Futzing with gdb sources means gdb is talking directly to
> > the board and therefore is much easier to debug (when things aren't
> > working) (and by "debug" here I mean debug the gdb/target connection).
>
> Note that I've never used rproxy, but it's On My List Of Things To Get
> To (tm).
>
> The main reason I find the rproxy approach appealing is because it
> doesn't tie you to a particular version of gdb.  I know that gdb
> internals have been stable for some time, as has the RSP, but I *hate*
> patching the stock GNU sources because then I have a one-off that *I*
> have to distribute and keep up to date while the gdb developers charge
> relentlessly into the future, or wherever they're headed.  :^)
>
> The rproxy code base is smaller, I'd rather deal with the headache of
> keeping *that* up to date.  And I like the "distributed" nature of
> rproxy, since I don't always run under Linux (ditto for a lot of the
> people I work with).
>

The rproxy code is licenced with a BSD-type licence, making it more suitable
for certain work involving proprietry information.  The msp430 gdb guys used
rproxy because the jtag information for the msp430 was under NDA - they
could get around this by releasing that part of rproxy as binary-only, which
they could not do with a pure gdb solution.



------
Want more information?  See the CrossGCC FAQ, http://www.objsw.com/CrossGCC/
Want to unsubscribe? Send a note to crossgcc-unsubscribe@sources.redhat.com