[RFC] plugin/extension interface

[Russell Shaw]

Daniel Jacobowitz wrote:
> 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.

It would be useful if the manual actually said that this is the way to
add new commands for an external monitor. It is bad when i can only learn
new things about gdb by complaining.

>>>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.

I suppose i could start the shim daemon from a .gdbinit file using the
gdb "shell" command.

An explanation about shims and how to implement them in a way that is
non-tedious to use, should be in the manual.

Last time i read the remote protocol spec in the gdb manual, most of it
was too terse to be useable.