This is the mail archive of the
mailing list for the GDB project.
Re: How to write native (i.e. C/C++) plugin for gdb?
- From: Dmitry Samersoff <dms at samersoff dot net>
- To: Doug Evans <dje at google dot com>
- Cc: Joel Brobecker <brobecker at adacore dot com>, Hui Zhu <teawater at gmail dot com>, "gdb at sourceware dot org" <gdb at sourceware dot org>, Abhijith Halder <abhijit dot k dot halder at gmail dot com>
- Date: Fri, 27 Dec 2013 18:15:13 +0400
- Subject: Re: How to write native (i.e. C/C++) plugin for gdb?
- Authentication-results: sourceware.org; auth=none
- References: <52B97EB4 dot 9070100 at samersoff dot net> <CANFwon3gOuaopfsJ_Eord=14U__zD2JrBorKz_4bMBYPtZy4cQ at mail dot gmail dot com> <52B9966B dot 8050104 at samersoff dot net> <20131224144704 dot GJ4558 at adacore dot com> <52BAFA96 dot 8060407 at samersoff dot net> <52BB0D06 dot 3000208 at samersoff dot net> <CADPb22Sicg2Z6bsqWYq9Ok5FmijcH9+qmnSkMJXnUETRfeZeHQ at mail dot gmail dot com>
-----BEGIN PGP SIGNED MESSAGE-----
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
> <email@example.com> 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
I really like python (e.g. here is pure python elf reader and
disassemblers for arm, sparc and x86
http://www.samersoff.net/hg/pydas/ 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.
> To get a better picture of native plugins in action, please, take
> a look at solaris mdb.
> On 2013-12-25 19:32, Dmitry Samersoff wrote:
>>>> Thank you for the response.
>>>> I found this patch
>>>> https://sourceware.org/ml/gdb-patches/2012-05/msg00500.html -
>>>> 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?
>>>> On 2013-12-24 18:47, Joel Brobecker wrote:
>>>>>> I need to implement scenario like one below:
>>>>>> (gdb) load-plugin libgdbjvm.so (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
Saint Petersburg, Russia, http://devnull.samersoff.net
* There will come soft rains ...
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.20 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
-----END PGP SIGNATURE-----