Mirror of the gdb mailing list
 help / color / mirror / Atom feed
From: Mark Kettenis <mark.kettenis@xs4all.nl>
To: andrew.stubbs@st.com
Cc: gdb@sourceware.org
Subject: Re: [RFC] plugin/extension interface
Date: Fri, 02 Dec 2005 19:36:00 -0000	[thread overview]
Message-ID: <200512021936.jB2JaZ6n014666@elgar.sibelius.xs4all.nl> (raw)
In-Reply-To: <439090FE.8040502@st.com> (message from Andrew STUBBS on Fri, 02 	Dec 2005 18:22:54 +0000)

> Date: Fri, 02 Dec 2005 18:22:54 +0000
> From: Andrew STUBBS <andrew.stubbs@st.com>
> 
> Hi all,
> 
> I would like to test the waters and find out what your opinion would be 
> on the subject of a GDB plugin/extension interface.

My initial reaction (without reading the rest of your mail) would be
"Not over my dead body!".  In my experience plugin/extension
interfaces add a lot of bloat, are difficult to maintain, and
difficult to support.  Look at the problems we've had with the
libthread-db.so stuff on Linux and (to a lesser extent) Solaris.
There are also GPL issues.

> We, here at ST, have a custom target backend which is implemented as a 
> DLL connected to some custom code in GDB not totally unlike remote.c. We 
> did this because the remote protocol was too slow, too limited and 
> required some way to launch other processes which could then easily get 
> left over by mistake.
> 
> Now we have reason to rewrite the interface - it is currently very 
> SH-centric and we wish to share it with another ST architecture - so I 
> am considering the various possibilities.
> 
> One possibility (of which I am in favour) is to create a generic GDB 
> plugin interface which can become part of the official GDB. This course 
> of action is not yet certain, but the outcome of any discussion we have 
> here will probably influence the final decision (along with some other 
> local considerations).
> 
> Desirable features (from our point of view):
> - Target independent [1].
> - Architecture independent [1].
> - Flexible/Powerful enough not to limit capabilities.
> - Debugger independent [2].
> - Extensible.
> - Easy to maintain.
> 
> It is largely this last requirement which prompts me to ask your opinion 
> - it will be easier to maintain if it is accepted into the official 
> source base, because we will not have to continually forward port it as 
> a local change. Obviously I am more likely to get something accepted if 
> you guys have agreed the interface in principle in advance.

Why can't you just compile your remote protocol support code into GDB.
That's the way it's been always done.  It's simple, and works, and I
think that'll actually be the easiest to maintain.  Plugin/extension
interfaces only make sense for third parties that want to distribute
binary stuff.  That doesn't make sense for an open source debugger.

Mark


  parent reply	other threads:[~2005-12-02 19:36 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 [this message]
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               ` Bob Rossi
2005-12-03  2:41               ` Russell Shaw
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-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=200512021936.jB2JaZ6n014666@elgar.sibelius.xs4all.nl \
    --to=mark.kettenis@xs4all.nl \
    --cc=andrew.stubbs@st.com \
    --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