This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: GDB plugin
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