From: Dmitry Samersoff <dms@samersoff.net>
To: Doug Evans <dje@google.com>
Cc: Joel Brobecker <brobecker@adacore.com>,
Hui Zhu <teawater@gmail.com>,
"gdb@sourceware.org" <gdb@sourceware.org>,
Abhijith Halder <abhijit.k.halder@gmail.com>
Subject: Re: How to write native (i.e. C/C++) plugin for gdb?
Date: Fri, 27 Dec 2013 14:15:00 -0000 [thread overview]
Message-ID: <52BD8B71.3050506@samersoff.net> (raw)
In-Reply-To: <CADPb22Sicg2Z6bsqWYq9Ok5FmijcH9+qmnSkMJXnUETRfeZeHQ@mail.gmail.com>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Doug,
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
> <dms@samersoff.net> 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
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.
- -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
>>>> 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?
>>>>
>>>> -Dmitry
>>>>
>>>> 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
>>>>> C?
>>>>
>>>>
>>>>
>>>>
>
- --
Dmitry Samersoff
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/
iQEcBAEBAgAGBQJSvYtxAAoJEHEy08c4gIABuNYH/RLGcE+cF1wkcALL+Jnoj3iV
xHPjQ0FsTakAPzuVin+9eXXS6I+Ap3ShNO+mhklAslIuf+Cb8xdK8Ocap0LyZ6o+
j23CRcKqDLVR3IZzgdlVbopm4fh1tqiy4CbSRGi8Yd7A0Z7i0eDvWEkRCLkbm7WU
IpQtcjB+ZUJXEFAqJZ4pVbg7lzUVtBx86o00BbUqbJxGtW+aFGULXCZyu5PZAans
7/5cA7u9GI94bXt2vX95SPgBJN9LSRjyMOI6InMGIVOhAtNbwsThYAqaZ577Qt5g
cgw3lWO+4P3g8qcxZs6U4W1tdTOXrhIYzLlq21Tn26Rx/eg/4m9gG5LfOHHrNFU=
=GZ8+
-----END PGP SIGNATURE-----
prev parent reply other threads:[~2013-12-27 14:15 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-12-24 12:31 Dmitry Samersoff
2013-12-24 13:16 ` Hui Zhu
2013-12-24 14:13 ` Dmitry Samersoff
2013-12-24 14:47 ` Joel Brobecker
2013-12-25 15:32 ` Dmitry Samersoff
2013-12-25 16:51 ` Dmitry Samersoff
2013-12-26 22:55 ` Doug Evans
2013-12-27 14:15 ` Dmitry Samersoff [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=52BD8B71.3050506@samersoff.net \
--to=dms@samersoff.net \
--cc=abhijit.k.halder@gmail.com \
--cc=brobecker@adacore.com \
--cc=dje@google.com \
--cc=gdb@sourceware.org \
--cc=teawater@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox