custom runtime GDB extensions

custom runtime GDB extensions

[Bruce Korb]

Hi,

I don't know exactly why the dlopen of shared objects is disparaged,
because I couldn't find references via Googling.  Anyway, my desire
was to augment GDB with code derived from compiled C code that
converts back and forth between bit masks and bit names.  I didn't
want to convert C to Python and I didn't want to maintain separate
Python code by hand.  So, I wanted wrapper code that could implement
GDB extensions.  I did find references to, "so we don't want C code,
so we'll do it in Python", but no references to the rationale.

So, anyway, thank you, Abhijit.  I've successfully applied your
patch.  Now to my main point:  why not use shared libraries?
I'm working on an open source project that uses many, many bit maps
and it would be convenient to be able to read the bitmaps without
having to refer to header files with series of definitions like:

#define MUMBLE 0x8000000000000000000ULL

Re: custom runtime GDB extensions

[Tom Tromey]

>>>>> "Bruce" == Bruce Korb <bruce.korb@gmail.com> writes:

Bruce> I don't know exactly why the dlopen of shared objects is
Bruce> disparaged, because I couldn't find references via Googling.

I think the fundamental reason is that we don't want to keep C API
compatibility in gdb.

There's the JIT API, of course, but it is intentionally very limited.

Tom

Re: custom runtime GDB extensions

[Bruce Korb]

Hi Tom,

Thank you.

On Mon, Oct 22, 2012 at 2:01 PM, Tom Tromey <tromey@redhat.com> wrote:
>>>>>> "Bruce" == Bruce Korb <bruce.korb@gmail.com> writes:
>
> Bruce> I don't know exactly why the dlopen of shared objects is
> Bruce> disparaged, because I couldn't find references via Googling.
>
> I think the fundamental reason is that we don't want to keep C API
> compatibility in gdb.
>
> There's the JIT API, of course, but it is intentionally very limited.

Perhaps that is the ticket.  I don't really want access to lots of internals,
my goal is to be able to call a dynamically loaded function that can print
some information about the arguments passed in, as exampled below.
If the "JIT API" is up to that task, then I don't need anything grander.
I searched backward from dlopen to functions that used it and didn't
trace my way to anything I could figure out how to use.

(gdb) plugin add ~/work/GIT/flag-project/mask-disp.so
(gdb) mask
The following mask types are supported:

        at-flag
        cfg-flag
        config-flag
        ldd-flag
        ldlm-cancel-flag
        ldlm-flag
        ll-file-flag
        llog-ctxt-flag
        llog-flag
        llog-misc-flag
        lmd-flag
        obd-connect-flag
        obd-flag
        obd-incompat-flag
        obd-llog-flag
        os-state-flag
        ptlrpc-reply-flag
        ptlrpc-sec-flag
(gdb) mask obd-flag all
0xF03FFF7F represents:
        inlinedata obdmdexists delorphan norpc idonly recreate_objs
        debug_check no_usrquota no_grpquota create_crow srvlock
        cksum_crc32 cksum_adler cksum_crc32c cksum_rsvd2 cksum_rsvd3
        shrink_grant mmap recov_resend nospc_blk short_io local-1
        local-2 local-3 local-4
(gdb) mask obd-flag srvlock short_io obdmdexists
0x200802 represents:
        obdmdexists srvlock short_io
(gdb) mask obd-flag 0707
0x147 represents:
        inlinedata obdmdexists delorphan debug_check no_usrquota

Re: custom runtime GDB extensions

[Tom Tromey]

>>>>> "Bruce" == Bruce Korb <bruce.korb@gmail.com> writes:

Tom> There's the JIT API, of course, but it is intentionally very limited.

Bruce> If the "JIT API" is up to that task, then I don't need anything grander.

I'm pretty sure it isn't.

Bruce> (gdb) mask
[...]

You can write a Python extension that loads your C code using ctypes.
There are other viable choices as well.

Tom

Re: custom runtime GDB extensions

[Bruce Korb]

Hi Tom,

On Tue, Oct 23, 2012 at 12:10 PM, Tom Tromey <tromey@redhat.com> wrote:
> Bruce> (gdb) mask
> [...]
>
> You can write a Python extension that loads your C code using ctypes.
> There are other viable choices as well.

I'd have to learn Python or one of the other viable choices.
I am looking for/hoping for a nice, simple cookbook solution that
doesn't involve learning how to set up Python or swig interfaces,
rebuilding gdb with python hooks and gluing together all the pieces.
Something simple.  Applying Abhijit's patch and writing the 10 line
hook function was a simple cookbook solution.  Except it does
involve rebuilding GDB, so still not as simple as I'd like.

A pointer to a cook book would be really helpful. Thank you so much!

Regards, Bruce

Re: custom runtime GDB extensions

[Joel Brobecker]

> A pointer to a cook book would be really helpful. Thank you so much!

My point of view of a "cookbook" solution to extending GDB would be to
use the Python extension interface. It does depend on having a GDB that
includes Python support, but python suppport has been around for a while,
now, so I do not think it is an unreasonable assumption.

-- 
Joel

Re: custom runtime GDB extensions

[Bruce Korb]

On Tue, Oct 23, 2012 at 12:49 PM, Joel Brobecker <brobecker@adacore.com> wrote:
>> A pointer to a cook book would be really helpful. Thank you so much!
>
> My point of view of a "cookbook" solution to extending GDB would be to
> use the Python extension interface. It does depend on having a GDB that
> includes Python support, but python suppport has been around for a while,
> now, so I do not think it is an unreasonable assumption.

OK, I do not speak Python.  I have a library of C code that does what I need.
Since no distribution I regularly use regularly enables python extensions for
GDB, I will, therefore, need to rebuild GDB with python enabled and I need
to find how to code up python-into-shared-library calls.  Likely also how to
load said shared library.  That is a lot of work just for a GDB-into-object-code
glue layer.  I'll do it, but please help me with a short cut that does
not entail
the deep recesses of Python for dlopen-ing and calling into shared libraries.
An example would do very nicely.  I have googled for this and the lack of
results has me here.  Again, please and thank you! :)   Regards, Bruce

Re: custom runtime GDB extensions

[Tom Tromey]

Bruce> I'd have to learn Python or one of the other viable choices.

Yes.

Bruce> I am looking for/hoping for a nice, simple cookbook solution that
Bruce> doesn't involve learning how to set up Python or swig interfaces,
Bruce> rebuilding gdb with python hooks and gluing together all the pieces.
Bruce> Something simple.

Sorry, that doesn't exist.

Bruce> A pointer to a cook book would be really helpful. Thank you so much!

ctypes tutorial: http://python.net/crew/theller/ctypes/tutorial.html

Somewhat out of date but still generally useful gdb-python walk-through:
http://sourceware.org/gdb/wiki/PythonGdbTutorial

Tom

Re: custom runtime GDB extensions

[Bruce Korb]

Hi Tom,

On Tue, Oct 23, 2012 at 1:28 PM, Tom Tromey <tromey@redhat.com> wrote:
> Bruce> Something simple.
>
> Sorry, that doesn't exist.

:(

> Bruce> A pointer to a cook book would be really helpful. Thank you so much!
>
> ctypes tutorial: http://python.net/crew/theller/ctypes/tutorial.html
>
> Somewhat out of date but still generally useful gdb-python walk-through:
> http://sourceware.org/gdb/wiki/PythonGdbTutorial

THAT'S THE TICKET!  Thank you again.  Once I've jiggered up a way
to readily load a .so and invoke a function from it, I'll post it so the next
guy might find the thing with Google.  Meanwhile, cajoling the distributions
to enable python extensions by default would be a good thing to do.
(Or just do it by default and require a --disable-python option instead....)

Re: custom runtime GDB extensions

[Tom Tromey]

>>>>> "Bruce" == Bruce Korb <bruce.korb@gmail.com> writes:

Bruce> Meanwhile, cajoling the distributions to enable python extensions
Bruce> by default would be a good thing to do.

I thought the distros did do this nowadays; but I don't really know much
about any other than Fedora any more.  FWIW, Fedora enables Python here
and also ships with all the other little things that help gdb -- at
least Python pretty-printers for libstdc++, libgcc hooks for unwinding,
glibc hooks for improved dlopen support and longjmp.

If your distro doesn't do this I suggest filing bugs with them.

Bruce> (Or just do it by default and require a --disable-python option
Bruce> instead....)

Not touching that one :-)

Tom