This is the mail archive of the crossgcc@sources.redhat.com mailing list for the crossgcc project.
See the CrossGCC FAQ for lots more information.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
> > > > 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
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |