This is the mail archive of the 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: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

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

Not very helpful.

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

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.

All this daemon stuff to convert a generic protocol to a hardware-specific
protocol is slow and ineligant IMO.

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

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.

Changes in gdb that break these interfaces simply mean the maintainers
of them can adapt to the change, so not hindering gdb development.

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

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