Re: [RFC] plugin/extension interface

[Daniel Jacobowitz <drow@false.org>]

On Sat, Dec 03, 2005 at 03:05:25PM +1100, Russell Shaw wrote:
> Well that's just too bad. It's the best way to go. Atleast i can support
> my own private gdb and cut the cruft that's been holding it back for years.

You can do that anyway.  Maintain your own source tree based on a
current release; it's not that hard, lots of people do this already.

> The very concept of making a protocol conversion program act like an
> end target is totally flawed.

Obviously I disagree; I don't find any of the limitations you describe
to be a serious problem in practice.

And yes, we've written and used several of these shim layers here.

> The second problem is that ICE hardware and other debuggers have
> various specific commands such as for setting ICE hardware
> parameters, selecting memory spaces, setting breakpoint paramteters,
> and a ton of other stuff that a generic protocol has no hope of
> addressing.

Please see the "monitor" command, which lets you pass whatever you wish
to the convertor.  This and a couple of user-defined commands are most
of what you need...

> I found that by registering my own commands with add_com(), i can do
> all kinds of excellent things such as spit out on the gdb output
> window a tabulated list of the fuse settings in a microcontroller, or
> display and set the current ICE hardware settings.

... and they can provide arbitrary output, also.  If it's inadequate
for what you want to do with it, please provide specific examples, and
we can fix it.

> With a defined interface for vendors to control specific debugger
> hardware, gdb would get a lot more interest and move lightyears
> ahead. All i've seen is stagnation ever since i've had an interest in
> gdb 5 years ago.

You might be surprised to know that there's a thriving market for this
sort of conversion layer already, e.g. OCDRemote.

As for the state of GDB, that's a separate thread, and making progress
already.

-- 
Daniel Jacobowitz
CodeSourcery, LLC