Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Matt Rice <ratmice@gmail.com>
To: Hui Zhu <teawater@gmail.com>
Cc: Tom Tromey <tromey@redhat.com>,
	Abhijit Halder <abhijit.k.halder@gmail.com>,
		"gdb-patches@sourceware.org ml" <gdb-patches@sourceware.org>
Subject: Re: GDB plugin
Date: Tue, 08 May 2012 14:38:00 -0000	[thread overview]
Message-ID: <CACTLOFqipBHSp86Z_1xEGgAcWkXNk_KRZmePMY_XPge_ADOTiQ@mail.gmail.com> (raw)
In-Reply-To: <CANFwon1ATQxMciu6X-HNWO+F218GayQ-c+mRvXq7dPiVPorV9g@mail.gmail.com>

On 5/7/12, Hui Zhu <teawater@gmail.com> wrote:
> On Tue, May 8, 2012 at 4:18 AM, Tom Tromey <tromey@redhat.com> wrote:
>>>>>>> "Abhijit" == Abhijit Halder <abhijit.k.halder@gmail.com> writes:
>>
>> Abhijit> Is there any way to load a GDB plugin (shared library having
>> extended
>> Abhijit> functionality) in current GDB? I am planning to develop one.
>> Need
>> Abhijit> yours opinion on this.
>>
>> There is a little bit of this for the JIT functionality.
>>
>> Generic plugins are trouble because they tend to fix the API -- but we
>> want to be able to change the API as needed.  The JIT approach avoided
>> this by exporting a custom, minimal API.
>>
>> What exactly are you planning to do?
>>
>> Tom
>
> I think the api is not a big trouble, the Linux kernel's api is always
> change.  But lkm is still alive.  I use some ifdef to make KGTP can be
> work from 2.6.18 to upstream.  I think if GDB can supply some
> interface to get the api version, support different api is not very
> hard.

all but a few of the kernel modules are actually shipped with the kernel though.
nor does the kernel have a python interpreter embedded in it.

I once saw some code which attempted to be compatible with various
versions of gdb and it was not pretty.
here's the commit where they decided to remove all of that and stick
to a single gdb version.

http://mspgcc.git.sourceforge.net/git/gitweb.cgi?p=mspgcc/gdb;a=commit;h=078b594406e6257930b3d6e66f226e9725cea874

personally I think it's just going to be a pain for those who write
plugins, much more so
than the effort of putting things upstream, we should encourage that,
not lead them into some #ifdef death trap.


  parent reply	other threads:[~2012-05-08 14:38 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-05-07 16:21 Abhijit Halder
2012-05-07 20:18 ` Tom Tromey
2012-05-08  5:46   ` Abhijit Halder
2012-05-08 14:20     ` Tom Tromey
2012-05-08 15:05       ` Joel Brobecker
2012-05-08 15:21         ` Mark Kettenis
2012-05-08 22:06     ` André Pönitz
2012-05-09  4:28       ` Abhijit Halder
2012-05-08  6:38   ` Hui Zhu
2012-05-08 13:46     ` Tom Tromey
2012-05-08 14:38     ` Matt Rice [this message]
2012-05-08 14:47       ` Paul_Koning
2012-05-08 14:58         ` Matt Rice

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=CACTLOFqipBHSp86Z_1xEGgAcWkXNk_KRZmePMY_XPge_ADOTiQ@mail.gmail.com \
    --to=ratmice@gmail.com \
    --cc=abhijit.k.halder@gmail.com \
    --cc=gdb-patches@sourceware.org \
    --cc=teawater@gmail.com \
    --cc=tromey@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