This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
Re: [RFC] plugin/extension interface
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