This is the mail archive of the mailing list for the GDB project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: How to write native (i.e. C/C++) plugin for gdb?

Hash: SHA1


Unfortunately, sustaining - i.e. fixing customer side issues, - has
different requirements comparing to development - you have much less
control on environment and have to support more versions and
configuration than usual.

see also below.

On 2013-12-27 02:55, Doug Evans wrote:
> On Wed, Dec 25, 2013 at 8:51 AM, Dmitry Samersoff
> <> wrote: Everyone,
> Just found a year old discussion about Abhijit proposal.
> So answering to upcoming question - why not a Python.
> Python is very good staff if your speak about source level
> debugging. If you have to debug optimized binary python doesn't
> help match for two reason -
> 1) you have to port all native data structure you plan to work
> with to python.

>> This typically isn't that hard an exercise, have you looked into
>> it?

I really like python (e.g. here is pure python elf reader and
disassemblers for arm, sparc and x86 written as a part of larger
project) but ...

Typical deadlock case requires me to deal with 10-20 structures.

 Counting different versions and separate big- and little- endian
representation in Python, it creates a real zoo. And it's a pain to
keep this zoo in sync with C version.

In some case I can invoke target process code and it gives an
alleviation but it not always possible.

Use appropriate c headers directly and write simple native plugin is
much easy and safer approach.

Both windbg and mdb supports native plugins so I had a chance to
compare different options in practice.

> 2) python performance is not always acceptable and you not always 
> ever able to run a python.
>> I'd like to see the data that shows the performance isn't
>> acceptable. This could just be mistaken impressions.

On many of arm or mips boards overhead of python interpreter within
debugging session is not acceptable. Not mentioning the fact, that I
have to install python to this board first as it typically not there.

 (Yes, emulation helps but it's not always an option - e.g. it doesn't
help to find that the program doesn't save one of FPU register on some
version of hardware)

Other example - walking through java heap. Re-implementation of
garbage collector code in Python to optimize the walking is rather
costly but without optimization it takes a while.

- -Dmitry

> To get a better picture of native plugins in action, please, take
> a look at solaris mdb.
> -Dmitry
> On 2013-12-25 19:32, Dmitry Samersoff wrote:
>>>> Joel,
>>>> Thank you for the response.
>>>> I found this patch 
>>>> -
>>>> many thanks to Abhijit.
>>>> 1. What is the reason to keep it off main trunk? Is there a
>>>> chance to have it changed?
>>>> 2. What API is available from within a plugin? i.e. how I
>>>> can access coredump memory?
>>>> -Dmitry
>>>> On 2013-12-24 18:47, Joel Brobecker wrote:
>>>>>> I need to implement scenario like one below:
>>>>>> (gdb) load-plugin (gdb) attach PID (gdb)
>>>>>> jvm show loaded-classes (gdb) jvm show java-threads (gdb)
>>>>>> jvm show code-cache
>>>>> Maybe you could add some routines in your program that are
>>>>> solely intended for debugging purposes, and then define
>>>>> commands that call those routines. Off hand, that's the
>>>>> only way I can think of. Otherwise, interface the C++ stuff
>>>>> you need from Python - if necessary, export some stuff to
>>>>> C?

- -- 
Dmitry Samersoff
Saint Petersburg, Russia,
* There will come soft rains  ...
Version: GnuPG v2.0.20 (GNU/Linux)
Comment: Using GnuPG with Thunderbird -


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]