python scripting in gdb update
It’s been a great while since I last posted about Python scripting in GDB, mostly because I’ve been busy coding the feature and getting it ready for upstream.
First of all, I’d like to take the opportunity to encourage people interested in using this feature to experiment with what we have implemented so far. The reason is that if you still can’t do what you want with the current code in the Python branch, we’d love to hear what you miss and implement it. We are working on what is useful for ourselves, and trying to decide what other people would find useful. But it’s not possible to imagine everything that people want to use this for, or even most things. Please refer to this wiki page to learn what currently works, what we plan to implement, and how to grab the code from the Python branch.
Feel free to write to the GDB mailing list or show up in the #gdb IRC channel at Freenode to discuss this work and/or bring your use case to our attention, so that we can support it. I hope that with enough input from prospective users we can ship something that’s immediately useful for most people, and avoid having to jump through hoops later and have to shoehorn something that we forgot to cater for initially, risking breaking scripts out there or ending up with an inconsistent API.
Anyway, back to business: I have just committed the second patch in the Python series! It exports GDB’s value subsystem to Python scripts. Basically, GDB values are objects which represent data in the inferior (GDB jargon for the program being debugged), holding its address in the inferior’s addressspace, its type and so on. See the “Python API” section in the GDB manual if you want to learn more about it (yes, we are even writing documentation for the feature!).
I committed the first patch back in August, but I didn’t mention it here because it didn’t do anything the user would find useful, really. It was just groundwork for the rest (autoconf and Makefile.in changes, a ‘python’ command in GDB which basically does nothing useful, initial documentation…). Still, it was about 1500 lines long (not counting the patch’s context)! This shows how much work it is to integrate Python support in GDB. I almost regret having joined this effort. 
The second patch also doesn’t allow the user to do anything useful yet, unfortunately. But it is noteworthy because it is a base upon which a lot of other Python support code depend upon. Also, it’s the first committed patch which actually exposes something from GDB to Python. It took a while to get this code ready for two reasons: one was that there was a long discussion regarding how the syntax of acessing struct/union/class elements. The other was that implementing the Value class involved playing with little-documented aspects of Python’s C interface, and it took me time to discover how to do what I needed.
Now my next step is to choose the next patch from the Python series to submit upstream, and get it ready for posting (i.e., fix FIXMEs, add testcases and documentation). This brings me to another thing I’d like to mention. Back in April when I first prepared the Python patch series, I naively thought that after cutting them out, it was just a matter of posting them, iterate through a few review/rework steps and they’d be committed. Simple enough. But here we are in mid-October and just two from nine patches went in (now it’s more like 15 patches in total)! What happened?
The problem is that we’ve been working in the branch in an experimental and exploratory way, just hacking together enough to get something useful done. This was necessary because we didn’t know exactly what we would want to expose from GDB to Python, and how we wanted to do that. As we progressed and discussed the results, things started to become clear. The problem is that now we have a lot to clean up, voids to fill, and above all documentation and testcases to write. This takes time.
At least, that was the problem with the first two patches. I noticed Tom Tromey started to write more documentation and tie more loose ends than in the beginning (me? I’ve just been working on the first two patches until they were ready. Didn’t write sexy new stuff since then…), so there’s hope that the next patches will be easier to work with. We still lack a lot of tests for the testsuite, though…
Thursday, October 16, 2008 at 04:07
Why is so difficult to get the python-gdb source? cloning three git repositories? come on! we need a simple tar ball!
Friday, October 17, 2008 at 00:37
Ok, I was too optimistic in asking everybody to jump in. This is early work, and some assembly is still required. If cloning a git repo and checking out a branch is sounds too difficult, then it is indeed better to wait a bit.
On the bright side, what we already merged into mainline GDB will appear in GDB’s weekly snapshot tarball. Though for now I admit there’s nothing useful there regarding Python support (as I mentioned in this post).
Friday, October 31, 2008 at 01:41
I am interested in gdb python and frequently visit to see the progress. I initially took the source from git and compiled to test the scripting functionality but it disappointed me very much because there was no support for representing a gdb value/expression. I hope it is fixed in this patch. Will try it once I get time.
Wednesday, November 5, 2008 at 11:20
Sorry, I didn’t understand what you mean with “representing a gdb value/expression”.
Do you mean storing an expression and then being able to eventually ask it to be evaluated by GDB? If so, would it solve your problem if you could store an expression as a string, and then pass it to a gdb.evaluate() function which would return a value for it?
If so, we can add such function, it should be easy. If not, what functionality would you need out of a python representation of an expression?
Thanks for your feedback, this is exactly the kind of input I need at this point.
Thursday, November 6, 2008 at 01:42
“Do you mean storing an expression and then being able to eventually
ask it to be evaluated by GDB? If so, would it solve your problem if
you could store an expression as a string, and then pass it to a
gdb.evaluate() function which would return a value for it?”
Although generating expression string and passing it to gdb.evaluate() looks little ugly, if it will work then I am happy with it.
What I tried was to print all elements in an AVL tree using python scripting.
The equivalent gdb user command(not working) is given below. Although the following command to specific to my project, I hope it will better explain my requirement.
define descriptor
set $arg0 = (VM_DESCRIPTOR_PTR)$arg0
if ! IS_AVL_TREE_LEFT_LIST_END( $arg0->tree_node )
set $left = STRUCT_ADDRESS_FROM_MEMBER( (AVL_TREE_PTR)AVL_TREE_LEFT_NODE( &$arg0->tree_node ), VM_DESCRIPTOR, tree_node)
descriptor $left
end
printf “%3d %10p %10p %10p %4d “, $arg0->reference_count, $arg0->start, $arg0->end, $arg0->unit, ($arg0->end-$arg0->start)/PAGE_SIZE
vm_prot &$arg0->protection.user_write
printf “\n”
if ! IS_AVL_TREE_RIGHT_LIST_END( $arg0->tree_node )
set $right = STRUCT_ADDRESS_FROM_MEMBER( (AVL_TREE_PTR)AVL_TREE_RIGHT_NODE( &$arg0->tree_node ), VM_DESCRIPTOR, tree_node)
descriptor $right
end
end
In the above example, IS_AVL_TREE_LEFT_LIST_END(), IS_AVL_TREE_RIGHT_LIST_END(),STRUCT_ADDRESS_FROM_MEMBER(),AVL_TREE_LEFT_NODE(), AVL_TREE_RIGHT_NODE() are macros. If gdb.evaluate() is implemented then I can use that function to execute/expand these C macros inside gdb get the value back into python.
http://sourceware.org/gdb/wiki/PythonGdb says – Breakpoints, blocks, frames, symbols, symbol tables, types, and values have Python representations. That means I can represent a C type inside python?
I would be very helpful, if you can write a small documentation for the existing work.
Thank you very much for the good effort.