From: Russell Shaw <rjshaw@netspace.net.au>
Cc: gdb@sourceware.org
Subject: Re: [RFC] plugin/extension interface
Date: Sat, 03 Dec 2005 03:13:00 -0000 [thread overview]
Message-ID: <43910D47.2070300@netspace.net.au> (raw)
In-Reply-To: <20051203024500.GA22826@nevyn.them.org>
Daniel Jacobowitz wrote:
> On Sat, Dec 03, 2005 at 01:41:35PM +1100, Russell Shaw wrote:
>
>>Months ago, i added a remote protocol for a hardware in-circuit emulator
>>and was going to write a chapter documenting how to add a target protocol
>>to gdb. My questions on how best to add this to gdb in cvs got no response
>>whatsoever. Now i've lost all interest.
>
> [Off-topic here, but]
>
> I can't even remember seeing messages from you on this topic; a certain
> amount of persistance is always called for in GDB development.
>
> However, in general, I've come to believe that GDB shouldn't continue
> to add support for new remote protocols. What we need is a nice,
> open-source framework for gdb remote <-> other remote conversion.
The way gdb works, when i type: target avrjtagice -d /dev/ttyS2,
gdb uses (or registers) using: void _initialize_remote_jtag (void).
It really looks like gdb is "loading" the module.
If the functions (or framework) used in these target interfaces are
documented, the problems would be solved with little other than a bit
of documentation work.
I couldn't use the default target protocol, because i wasn't interfacing
to an end target. I was interfacing to an ICE debugger (that already had
its own protocol) for the target.
I did it to replace the current hack of having an extra program on the
pc that converts between the default gdb target protocol, and this ICE-
specific protocol.
The conversion hack was extremely slow, clumsy, fault-intolerant, and error-prone.
With the specific interface in gdb, the performance was wonderful, and new gdb
commands can be easily registered for this ICE, that are only accessible after
the command "target avrjtagice -d /dev/ttyS2" is performed (like an emacs minor
mode or whatever).
Currently, the files for these specific interfaces are just chucked into gdb-6.3/gdb/
(such as remote-e7000.c).
What's really needed is a separate sub-directory for each of these remote-interface
protocol files, and a well documented api for what functions to use within them.
The api already exists, just look in any db-6.3/gdb/remote*.c. One of the subdirectories
can be devoted to the generic target protocol where the comms is to the end embedded
system, instead of an intermediate debugger box.
next prev parent reply other threads:[~2005-12-03 3:13 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-12-02 18:25 Andrew STUBBS
2005-12-02 18:49 ` Eli Zaretskii
2005-12-02 19:23 ` Daniel Jacobowitz
2005-12-02 19:36 ` Mark Kettenis
2005-12-02 22:12 ` Jim Blandy
2005-12-02 22:16 ` Daniel Jacobowitz
2005-12-02 22:41 ` Mark Kettenis
2005-12-02 23:07 ` Jim Blandy
2005-12-02 23:13 ` Bob Rossi
2005-12-02 23:32 ` Daniel Jacobowitz
2005-12-03 0:57 ` Jim Blandy
2005-12-03 2:32 ` Daniel Jacobowitz
2005-12-03 2:41 ` Russell Shaw
2005-12-03 2:45 ` Daniel Jacobowitz
2005-12-03 3:13 ` Russell Shaw [this message]
2005-12-03 3:33 ` Daniel Jacobowitz
2005-12-03 4:05 ` Russell Shaw
2005-12-03 4:14 ` Daniel Jacobowitz
2005-12-03 4:44 ` Russell Shaw
2005-12-03 4:49 ` Daniel Jacobowitz
2005-12-03 5:25 ` Russell Shaw
2005-12-03 12:49 ` [commit] Clarify "monitor" command (was: [RFC] plugin/extension interface) Eli Zaretskii
2005-12-03 12:51 ` [commit] Clarify "monitor" command Russell Shaw
2005-12-03 16:08 ` [commit] Clarify "monitor" command (was: [RFC] plugin/extension interface) Daniel Jacobowitz
2005-12-03 5:06 ` [RFC] plugin/extension interface Russell Shaw
2005-12-03 5:12 ` Daniel Jacobowitz
2005-12-03 9:29 ` Eli Zaretskii
2005-12-03 9:50 ` Russell Shaw
2005-12-03 9:57 ` Eli Zaretskii
2005-12-03 2:41 ` Bob Rossi
2005-12-05 16:17 ` Andrew STUBBS
2005-12-05 16:34 ` Bob Rossi
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=43910D47.2070300@netspace.net.au \
--to=rjshaw@netspace.net.au \
--cc=gdb@sourceware.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox