From: Russell Shaw <rjshaw@netspace.net.au>
Cc: gdb@sourceware.org
Subject: Re: [RFC] plugin/extension interface
Date: Sat, 03 Dec 2005 02:41:00 -0000 [thread overview]
Message-ID: <439105DF.5040708@netspace.net.au> (raw)
In-Reply-To: <20051203023154.GA22527@nevyn.them.org>
Daniel Jacobowitz wrote:
> On Fri, Dec 02, 2005 at 04:57:01PM -0800, Jim Blandy wrote:
>
>>On 12/2/05, Daniel Jacobowitz <drow@false.org> wrote:
>>
>>>And every one of these things you've described doing with debuggers,
>>>would require a _DIFFERENT_ plugin interface. It would be a nightmare
>>>to add this to today's GDB!
>>
>>Oh, I figured we'd just let the plugin code #include GDB's headers
>>directly, so they could get at whatever they wanted.
>>
>>... okay, that does sound like a nightmare.
>
> Now we're communicating :-)
>
> For the record, here's my overall point in this thread. We have some
> very good abstraction layers already: in particular, I'm talking about
> the remote protocol, and the MI/interpreters mechanism. I want GDB to
> be more extensible, but I believe that those protocols are the best way
> to do it. They both have limitations for this kind of use, because
> they aren't used that way yet; but what we need to do is commit to
> using them, then bite the bullet and begin improving them to meet our
> needs.
>
> That way we can keep the interfaces coherent, and hopefully,
> documented at or above today's levels.
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.
next prev parent reply other threads:[~2005-12-03 2:41 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 [this message]
2005-12-03 2:45 ` Daniel Jacobowitz
2005-12-03 3:13 ` Russell Shaw
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=439105DF.5040708@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