* custom runtime GDB extensions
@ 2012-10-21 23:35 Bruce Korb
2012-10-22 21:01 ` Tom Tromey
0 siblings, 1 reply; 10+ messages in thread
From: Bruce Korb @ 2012-10-21 23:35 UTC (permalink / raw)
To: Abhijit Halder, gdb
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
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: custom runtime GDB extensions
2012-10-21 23:35 custom runtime GDB extensions Bruce Korb
@ 2012-10-22 21:01 ` Tom Tromey
2012-10-22 22:01 ` Bruce Korb
0 siblings, 1 reply; 10+ messages in thread
From: Tom Tromey @ 2012-10-22 21:01 UTC (permalink / raw)
To: Bruce Korb; +Cc: Abhijit Halder, gdb
>>>>> "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
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: custom runtime GDB extensions
2012-10-22 21:01 ` Tom Tromey
@ 2012-10-22 22:01 ` Bruce Korb
2012-10-23 19:10 ` Tom Tromey
0 siblings, 1 reply; 10+ messages in thread
From: Bruce Korb @ 2012-10-22 22:01 UTC (permalink / raw)
To: Tom Tromey; +Cc: Abhijit Halder, gdb
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
^ permalink raw reply [flat|nested] 10+ messages in thread* Re: custom runtime GDB extensions
2012-10-22 22:01 ` Bruce Korb
@ 2012-10-23 19:10 ` Tom Tromey
2012-10-23 19:42 ` Bruce Korb
0 siblings, 1 reply; 10+ messages in thread
From: Tom Tromey @ 2012-10-23 19:10 UTC (permalink / raw)
To: Bruce Korb; +Cc: Abhijit Halder, gdb
>>>>> "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
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: custom runtime GDB extensions
2012-10-23 19:10 ` Tom Tromey
@ 2012-10-23 19:42 ` Bruce Korb
2012-10-23 19:49 ` Joel Brobecker
2012-10-23 20:28 ` Tom Tromey
0 siblings, 2 replies; 10+ messages in thread
From: Bruce Korb @ 2012-10-23 19:42 UTC (permalink / raw)
To: Tom Tromey; +Cc: Abhijit Halder, gdb
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
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: custom runtime GDB extensions
2012-10-23 19:42 ` Bruce Korb
@ 2012-10-23 19:49 ` Joel Brobecker
2012-10-23 20:01 ` Bruce Korb
2012-10-23 20:28 ` Tom Tromey
1 sibling, 1 reply; 10+ messages in thread
From: Joel Brobecker @ 2012-10-23 19:49 UTC (permalink / raw)
To: Bruce Korb; +Cc: Tom Tromey, Abhijit Halder, gdb
> 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
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: custom runtime GDB extensions
2012-10-23 19:49 ` Joel Brobecker
@ 2012-10-23 20:01 ` Bruce Korb
0 siblings, 0 replies; 10+ messages in thread
From: Bruce Korb @ 2012-10-23 20:01 UTC (permalink / raw)
To: Joel Brobecker; +Cc: Tom Tromey, Abhijit Halder, gdb
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
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: custom runtime GDB extensions
2012-10-23 19:42 ` Bruce Korb
2012-10-23 19:49 ` Joel Brobecker
@ 2012-10-23 20:28 ` Tom Tromey
2012-10-23 20:54 ` Bruce Korb
1 sibling, 1 reply; 10+ messages in thread
From: Tom Tromey @ 2012-10-23 20:28 UTC (permalink / raw)
To: Bruce Korb; +Cc: Abhijit Halder, gdb
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
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: custom runtime GDB extensions
2012-10-23 20:28 ` Tom Tromey
@ 2012-10-23 20:54 ` Bruce Korb
2012-10-23 21:01 ` Tom Tromey
0 siblings, 1 reply; 10+ messages in thread
From: Bruce Korb @ 2012-10-23 20:54 UTC (permalink / raw)
To: Tom Tromey; +Cc: Abhijit Halder, gdb
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....)
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: custom runtime GDB extensions
2012-10-23 20:54 ` Bruce Korb
@ 2012-10-23 21:01 ` Tom Tromey
0 siblings, 0 replies; 10+ messages in thread
From: Tom Tromey @ 2012-10-23 21:01 UTC (permalink / raw)
To: Bruce Korb; +Cc: Abhijit Halder, gdb
>>>>> "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
^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2012-10-23 21:01 UTC | newest]
Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2012-10-21 23:35 custom runtime GDB extensions Bruce Korb
2012-10-22 21:01 ` Tom Tromey
2012-10-22 22:01 ` Bruce Korb
2012-10-23 19:10 ` Tom Tromey
2012-10-23 19:42 ` Bruce Korb
2012-10-23 19:49 ` Joel Brobecker
2012-10-23 20:01 ` Bruce Korb
2012-10-23 20:28 ` Tom Tromey
2012-10-23 20:54 ` Bruce Korb
2012-10-23 21:01 ` Tom Tromey
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).