GDB plugin

GDB plugin

[Abhijit Halder]

Hi all,

Is there any way to load a GDB plugin (shared library having extended
functionality) in current GDB? I am planning to develop one. Need
yours opinion on this.

Thanks,
Abhijit Halder

Re: GDB plugin

[Tom Tromey]

>>>>> "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

Re: GDB plugin

[Abhijit Halder]

On Tue, May 8, 2012 at 1:48 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?
>
I am planning to introduce a pluggin command in GDB which will give a
flexibility to a GDB user to develop his/her own GDB extension (e.g.
GDB-ext.so). The extension may have new and/or extended functionality
like support for new languages and platforms and custom GDB-command.
The extension can be loaded by this newly proposed plugin command.

I am not completely aware of the limitation of this approach, but it
makes me happy thinking that the GDB users who want to extend GDB
functionality but are not well accustomed with GDB source code, can
still write their own pluggins and use an enhanced GDB without the
pain of recompilation of entire GDB source code.

Thanks,
Abhijit Halder

> Tom

Re: GDB plugin

[Tom Tromey]

>>>>> "Abhijit" == Abhijit Halder <abhijit.k.halder@gmail.com> writes:

Abhijit> I am planning to introduce a pluggin command in GDB which will give a
Abhijit> flexibility to a GDB user to develop his/her own GDB extension (e.g.
Abhijit> GDB-ext.so). The extension may have new and/or extended functionality
Abhijit> like support for new languages and platforms and custom GDB-command.
Abhijit> The extension can be loaded by this newly proposed plugin command.

Abhijit> I am not completely aware of the limitation of this approach, but it
Abhijit> makes me happy thinking that the GDB users who want to extend GDB
Abhijit> functionality but are not well accustomed with GDB source code, can
Abhijit> still write their own pluggins and use an enhanced GDB without the
Abhijit> pain of recompilation of entire GDB source code.

I think most users are better off writing extensions in Python.
We can expose more internals to Python as needed for this.

Tom

Re: GDB plugin

[Joel Brobecker]

> I think most users are better off writing extensions in Python.
> We can expose more internals to Python as needed for this.

I very much agree.

-- 
Joel

Re: GDB plugin

[Mark Kettenis]

> Date: Tue, 8 May 2012 08:05:10 -0700
> From: Joel Brobecker <brobecker@adacore.com>
> 
> > I think most users are better off writing extensions in Python.
> > We can expose more internals to Python as needed for this.
> 
> I very much agree.

Same here.

Re: GDB plugin

[André Pönitz]

On Tue, May 08, 2012 at 11:16:11AM +0530, Abhijit Halder wrote:
> [...] I am not completely aware of the limitation of this approach,
> but it makes me happy thinking that the GDB users who want to extend
> GDB functionality but are not well accustomed with GDB source code,
> can still write their own pluggins and use an enhanced GDB without the
> pain of recompilation of entire GDB source code.

I guess I fit the bill of a "user[s] who want to extend GDB
functionality but are not well accustomed with GDB source code"
rather well. It's something I've been doing for quite a while now.
However, the idea of writing plugins for GDB is not exactly
appealing to me.

For one. the "pain of recompilation of entire GDB source code" you
mention does not exist. It's a straight-forward ./configure &&
make, not even with enough waiting time for a successful trip to
the coffee maker (Unless you are on Windows and need to build all
dependencies, but that would not be different for plugins)

Secondly, GDB is pretty extensible using Python scripting already,
giving "zero compile time" and platform independent access to a lot
of functionality. It's hard to see how compiled plugins would
improve that situation. I'd rather expect the effort for creating
and maintaining a plugin interface to eat into the already scarce
resources of the developers, for really not much benefit.

So, please, pretty please, can we drop the idea? ;-)

Andre'

Re: GDB plugin

[Abhijit Halder]

On Wed, May 9, 2012 at 3:36 AM, André Pönitz
<andre.poenitz@mathematik.tu-chemnitz.de> wrote:
> On Tue, May 08, 2012 at 11:16:11AM +0530, Abhijit Halder wrote:
>> [...] I am not completely aware of the limitation of this approach,
>> but it makes me happy thinking that the GDB users who want to extend
>> GDB functionality but are not well accustomed with GDB source code,
>> can still write their own pluggins and use an enhanced GDB without the
>> pain of recompilation of entire GDB source code.
>
> I guess I fit the bill of a "user[s] who want to extend GDB
> functionality but are not well accustomed with GDB source code"
> rather well. It's something I've been doing for quite a while now.
> However, the idea of writing plugins for GDB is not exactly
> appealing to me.
>
> For one. the "pain of recompilation of entire GDB source code" you
> mention does not exist. It's a straight-forward ./configure &&
> make, not even with enough waiting time for a successful trip to
> the coffee maker (Unless you are on Windows and need to build all
> dependencies, but that would not be different for plugins)
>
> Secondly, GDB is pretty extensible using Python scripting already,
> giving "zero compile time" and platform independent access to a lot
> of functionality. It's hard to see how compiled plugins would
> improve that situation. I'd rather expect the effort for creating
> and maintaining a plugin interface to eat into the already scarce
> resources of the developers, for really not much benefit.
>
> So, please, pretty please, can we drop the idea? ;-)
>
> Andre'

Well, I am not fully aware of Python interface. If this proposed idea
does not make much any in current GDB, I will not push this.

Thanks,
Abhijit Halder

Re: GDB plugin

[Hui Zhu]

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.

Thanks,
Hui

Re: GDB plugin

[Tom Tromey]

>>>>> ">" == Hui Zhu <teawater@gmail.com> writes:

>> 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.

I'm skeptical, but I suppose as long as the rule is "if it breaks, too
bad", then it is ok.

Tom

Re: 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.

Re: GDB plugin

[Paul_Koning]

On May 8, 2012, at 10:38 AM, Matt Rice wrote:

> 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'm confused.  GDB is not a kernel component, so a GDB plugin isn't a kernel module.  How did lkm get brought into the discussion?

Extending GDB can done in a number of ways, but the Python way is quite flexible and easy when the things you need are available in its API.  And if they aren't, they can be added.

	paul

Re: GDB plugin

[Matt Rice]

On 5/8/12, Paul_Koning@dell.com <Paul_Koning@dell.com> wrote:
>
> On May 8, 2012, at 10:38 AM, Matt Rice wrote:
>
>> 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'm confused.  GDB is not a kernel component, so a GDB plugin isn't a kernel
> module.  How did lkm get brought into the discussion?

it was used as an example of an unstable API