GDB plugin

[Matt Rice]

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.