Re: [RFC] plugin/extension interface

[Daniel Jacobowitz <drow@false.org>]

On Sat, Dec 03, 2005 at 03:44:31PM +1100, Russell Shaw wrote:
> >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...
> 
> Looking at gdb docs, i couldn't find any "monitor" command or in the index.
> 
> (gdb) help monitor
> 
>   Send a command to the remote monitor (remote targets only).

Found `monitor' in Index. (`,' tries to find next.)

`monitor CMD'
     This command allows you to send commands directly to the remote
     monitor.

> Not very helpful.

That's because the bits that go after the word "monitor" depend on your
target :-)

> Anyway, preceding every command with "monitor" is hardly a nice or intuitive
> user interface.

Of course.  Provide a GDB script file that uses "define" to give things
pretty names, for example.

> >As for the state of GDB, that's a separate thread, and making progress
> >already.
> 
> If there was an api for hardware-specific protocols, not only would
> performance of these improve, but there would be new developers
> seeing gdb code and having an interest in maintaining and improving
> it (i was really the first example). What's more, all kinds of
> unsupported debugger hardware could be added by users. Because each
> hardware goes into its own subdirectory, it doesn't complicate any
> other area of gdb and can be easily removed. That's how the backend
> of gcc works.

I'm not convinced that performance is an issue here.  I'd need numbers. 
The total data transfer over the remote protocol is, usually, very
small - even if you're doing application downloads, it's just a couple
of extra buffer copies on the local system.  If you expect to be
transfering huge data sessions, use a local pipe or fifo to connect to
the daemon instead of TCP.

> A problem with the current method of using shims is that if you want
> to develop one, you have to go out and find one on the net to find a
> place to start.
> 
> With all the interfaces in gdb subdirectories, all the example code that
> anyone could ever want for adding support for new hardware, is already
> there to look at (i looked at gdb-6.3/gdb/remote*.c to start my one).

If you wanted to add a skeleton protocol conversion daemon to the GDB
source tree, especially under the GPL, I'm sure we'd be glad to include
it!

The problem with "remote*.c" is that most of them haven't been used in
years.  Many of them are bad examples, or simply broken.

-- 
Daniel Jacobowitz
CodeSourcery, LLC