From: "Paul A. Clarke" <pac@us.ibm.com>
To: gdb-patches@sources.redhat.com
Subject: Re: [PATCH] plugin patch
Date: Tue, 29 Oct 2002 07:55:00 -0000 [thread overview]
Message-ID: <1035906816.551.22.camel@pclarke> (raw)
In-Reply-To: <Pine.SUN.3.91.1021029082600.21619M@is>
On Tue, 2002-10-29 at 00:27, Eli Zaretskii wrote:
> On Mon, 28 Oct 2002, Scott Moser wrote:
> > Below is a patch to add plugin support to GDB. It exports a fairly
> > simple programmable interface for people to extend the functionality of
> > GDB via runtime loaded shared libraries in ways that may not fit with
> > the direction of the main GDB tree (not cross-platform, not stable,
> > niche audience...).
>
> IIRC, the FSF doesn't like to add to GNU software support for dynamically
> loading arbitrary modules (for fear of non-free libraries being used thru
> this).
It would be a shame to shun useful functionality due only to a fear of
certain uses. I know that, for other reasons, the Linux kernel added
licensing information to the kernel modules, to determine whether a
module would 'taint' the kernel. If it would be helpful to add that
sort of information to the plugin interface to make the patch more
palatable, that could certainly be done. This could also address
support issues where, for example, GDB crashes because of a bad plugin.
One could provide a lower level of support (or none) if GDB is
'tainted'. I think the Linux kernel module licensing awareness was
added mostly to address support issues.
The important thing, though, is that this is very useful functionality
in a small and isolated patch. One of our goals for making use of GDB
plugins is to add functionality which is "API-aware". In other words,
add apriori knowledge of the internals or state of a library to GDB, to
greatly enhance the debugging capabilities of GDB **with respect to
that, and only that library**.
A plugin interface would allow that useful functionality without
requiring either library-specific changes to core GDB or maintaining a
GDB patch indefinitely. Of course, the plugin itself has to be
maintained, especially without a "hardened" ABI (but that's a much
bigger deal for perhaps another day ;)
Regards,
Paul Clarke
next prev parent reply other threads:[~2002-10-29 15:55 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-10-28 14:01 Scott Moser
2002-10-28 22:28 ` Eli Zaretskii
2002-10-29 7:55 ` Paul A. Clarke [this message]
2002-11-06 6:45 ` Scott Moser
2002-11-06 6:56 ` Jelmer Vernooij
2002-11-06 7:13 ` Scott Moser
2002-11-06 7:54 ` Jelmer Vernooij
2002-11-06 9:14 ` Andrew Cagney
2002-11-06 15:07 ` Paul A. Clarke
2002-11-06 15:56 ` Andrew Cagney
2002-11-07 10:05 ` Paul A. Clarke
2002-11-07 11:57 ` Andrew Cagney
2002-11-07 13:10 ` Klee Dienes
2002-11-06 15:56 ` Andrew Cagney
2002-11-06 7:47 Howell, David P
2002-11-06 7:55 ` Daniel Jacobowitz
2002-11-06 11:12 ` Andrew Cagney
2002-11-06 11:55 ` Paul A. Clarke
2002-11-06 12:29 ` Andrew Cagney
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=1035906816.551.22.camel@pclarke \
--to=pac@us.ibm.com \
--cc=gdb-patches@sources.redhat.com \
/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