This is the mail archive of the gdb@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [RFC] plugin/extension interface


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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]