Posts Tagged ‘planet ltc’

Ok, so this time I won’t talk about Python scripting support in GDB. I’m getting tired of it myself. 🙂 I’ll just comment that it’s amazing the number of problems people in IRC report with GDB that can be solved with the Python support that we’re adding to it. Sometimes they need stuff which is only on the branch, but sometimes even the few bits already in CVS HEAD are enough!

Er, I actually do have one more thing to say about the subject: GDB had one project accepted in the Google Summer of Code 2009. Oguz Kayral is the student working on it, and I am his mentor. He will add support for subscribing to inferior events (e.g., signals, process and thread stops, thread creation) from Python. One use case for which this is useful was given by an IRC user at the #gdb channel:

<LimCore> how to run gdb from command line, so that it will run ./foo.bin with arguments: foo bar baz and it will run it instantly without waiting for ‘r’; And if program segfaults then it will do ‘bt’ without waiting for the command. (and if program terminates normally then it will also just quit)

LimCore will be able to write a simple and short Python script using the events API to solve his problem.

Now, moving on to other items: my team has been asked to improve GDB support for the hardware debug facilities in embedded PowerPC processors (for more info about these facilities, see Chapter 10 of Book III-E of the Power ISA v2.06). I announced this work to the GDB mailing list back in early March, and got useful insight from Joel Brobecker.

Today I posted an update on where we are with this work. We have the following ready for both native GDB and gdbserver on Linux:

  • one additional hardware watchpoint (two in total),
  • four hardware breakpoints,
  • one ranged hardware watchpoint.

And we still have the following features ahead of us:

  • support for the two DVC (Data Value Compare) registers, which enable hardware-accelerated conditions for hardware watchpoints,
  • two ranged hardware breakpoints.

Last and least, I was thinking of posting monthly GDB updates on what happened in GDB in the previous month as I did back in February, but I got busy and didn’t get around to it. I still entertain the idea though, so if you think it’s worth it, I’d be glad to know.

Read Full Post »

It’s been a while since I last talked about Python scripting support in GDB. Mostly because I’ve been focusing on getting stuff from the branch merged into CVS HEAD, so that GDB 7.0 can have some useful Python bindings.

The latest two patches committed upstream are for creating convenience functions in Python, and fo manipulating a program’s stack frames as Python objects. So, what can you do with those? I’ll borrow an example from Tom Tromey here: suppose you want to set a breakpoint which triggers only when the code is called by one specific function. You can create a convenience function like this:

import gdb
import re

class CallerIs (gdb.Function):
    """Return True if the calling function's name is equal to a string.
This function takes one or two arguments.
The first argument is the name of a function; if the calling function's
name is equal to this argument, this function returns True.
The optional second argument tells this function how many stack frames
to traverse to find the calling function.  The default is 1."""

    def __init__ (self):
        super (CallerIs, self).__init__ ("caller_is")

    def invoke (self, name, nframes = 1):
        frame = gdb.selected_frame ()
        while nframes > 0:
            frame = frame.older ()
            nframes = nframes - 1
        return frame.name () == name.string ()

CallerIs ()

And then create a conditional breakpoint using it, as in:

(gdb) break foo.c:42 if $caller_is ("some_function")

Or, to check the name of the grand-grand-caller of the code:

(gdb) break foo.c:42 if $caller_is ("some_function", 3)

Cool, huh? Now, why bother writing that big doc comment? GDB will use it as online help for the function you wrote:

(gdb) help function caller_is
Return True if the calling function's name is equal to a string.
This function takes one or two arguments.
The first argument is the name of a function; if the calling function's
name is equal to this argument, this function returns True.
The optional second argument tells this function how many stack frames
to traverse to find the calling function.  The default is 1.

One other patch which was merged in HEAD enables creating new GDB commands in Python, so you can write new commands to do some frame tricks too!

If you’d like to know more about the Python scripting work in GDB, I suggest you read the series of blog posts from Tom Tromey on this subject. It’ll give you a pretty good idea of what we have in the Python branch, and the direction we’re heading. Just keep in mind that some method names and syntax changed since he wrote that. Refer to the GDB manual in the Python branch (“make gdb.pdf” in gdb/doc/) or the example scripts (also in the Python branch, in gdb/python/lib/gdb/) for up-to-date details.

Read Full Post »

news from GDB-land

Nick Clifton publishes in his blog monthly news from the toolchain world, which is very interesting and very nice of him. Unfortunately he has not been able to provide news from GDB-land. I compiled a list of interesting events which happened in the GDB community this February to post as a comment in his blog, and figured it could be useful to post it here as well:

This is an incomplete list (doesn’t mention bugfixes, for instance) hacked up in the wee hours of the night, while waiting for sleep to come. If you are a GDB hacker who committed something interesting this month, I apologize in advance for not listing it here.

Read Full Post »

One annoying aspect of scripting GDB (using it’s own scripting language), is that if you test or set a variable which is not in scope, the script will generate an error and GDB will give up evaluating it. It would be useful to have a way to programatically check if the variable is in scope before trying to use it. There was even at least one try (from the brave Rob Quill) at implementing such a thing posted to the gdb-patches mailing list, but unfortunately as of now it still has some issues and haven’t been committed (I believe this patch is the latest version).

Anyway, this is the kind of thing we want to make easy to do in Python, so I decided to try to implement a solution using what we have in the Python branch. Tom Tromey already created the notion of convenience functions, which are functions that are implemented by GDB  that you can call in places where it accepts expressions, and he made it possible to implement such functions in Python. It follows that one can write a in_scope convenience function in Python which checks if a given variable name is valid in the current scope of the debugged program.

There were some missing pieces which I had to implement to get the in_scope function working (most notably, a method to get a string from a variable in the debugged program), and in the past few days I committed to the branch the patches which add those pieces. So now you can have the following script:

class InScope (gdb.Function):
    """Check if all the given variables or macros are in scope.
       Receives as argument a list of names separated by

    def __init__ (self):
        super (InScope, self).__init__ ("in_scope")

    def invoke (self, var):
        vars = set (var.string().split())
        found = set ()
        pc = gdb.get_selected_frame ().get_pc ()
        block = gdb.get_block_for_pc (pc)
        while block:
            for sym in block:
                if (sym.is_argument ()
                      or sym.is_constant ()
                      or sym.is_function ()
                      or sym.is_variable ()):
                    sym_name = sym.get_print_name ()
                    if sym_name in vars:
                        found.add (sym_name)
            block = block.get_superblock ()

        return vars == found

InScope ()

And use it like this:

Breakpoint 1, main (argc=1, argv=0x7fffffffe208) at /tmp/funcs.c:16
16        int i = 41;
(gdb) if $in_scope("i")
 >print "yay"
 >print "nay"
$1 = "yay"

If you save the script to ~/.gdb-in-scope.py, you can put the following in your ~/.gdbinit to load it automatically:

source ~/.gdb-in-scope.py

Now my goal is to cut out and submit upstream a set of patches to make the above work on regular GDB. The only problem is that I have the boring task of writing testcases and documentation for the code before I can submit it… 🙂

For now, If you want to use this script you can build a GDB from the branch, but be aware that the Python API as provided in the branch is subject to change.

Read Full Post »

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…

Read Full Post »

king of mustache

As Lucas “Well groomed” Meneghel already mentioned, LTC Brazil held the first King of Mustache contest (page in English now available, thanks to our mustache-adorned colleagues). As can be seen in the photo gallery, competition was fierce:

Or maybe not that much:

Yours truly also attempted to obtain the title, with what was later named the Santos Dumont look (oh well, judge for yourself):

In the end, Fred Mercury won:

Or was it Super Mario? This is still under debate.

Also Frederico, could not attend but sent this awesome picture anyway. And you can see all contestants here.

I’d like to send a big Thank You! to the people who organized this wondrous event: Alex Zanetti, André Macêdo and Paulo Vital. I had a really really good time that night!

Read Full Post »

I have finally found some time to write a bit about the GCC Developer’s Summit 2008, which happened one month ago in Ottawa, Canada (well, I didn’t really find time, since it’s past 1:30 AM now but still…).

In summary, I had a blast there! I was in last year’s summit and enjoyed it and learned a lot from it. But this time I already knew GDB people and they knew me, and I am involved in a couple of current developments and have more experience with the project, all of which made some difference. And everybody there is very friendly, of course, even if they never heard of you before. 🙂 In fact, Ian Taylor in his welcome presentation urged people to be friendly to newcomers since GCC and the GNU toolchain need new blood.

There was a good number of GDB-related events: a GDB talk and two debugging information talks, a debug information BoF, an informal GDB get-together and a GDB BoF. Unfortunately I know squat about GCC internals (I intend to learn more about it, but didn’t have a chance yet) so the two debugging information were above my head, and I absorbed little. The GDB talk was interesting but since I follow the GDB mailing lists I already knew most of what was presented.

The debug information BoF was interesting, especially since the discussion didn’t focus so much on the two competing approaches to improve debug information (which was the original point of the BoF), but mostly on what should be expected from debug information generated by GCC (i.e., what a debugger should be able to do with it, especially at higher optimization levels), and how its quality can be tested in the GCC testsuite.

The most interesting events for me were of course the GDB get-together and the GDB BoF. The former was a table reserved for us at lunch one day (thanks for organizing this, Joel Brobecker!) where folks interested in GDB would get to see each other faces and talk about random stuff (GDB-related or not). It was fun, and we were able to throw some ideas around about things such as conversion of the GDB repository from CVS to Subversion, the patch review process, and even about rewriting GDB in C++ (which is a hot thread in the GDB mailing list today!). I have a picture of the event:

If you follow the link you can see the notes with the name of each person in the photo above.

The GDB BoF was very interesting, and it felt weird to be at the front (thanks for inviting me Daniel!) discussing current GDB issues with Daniel Jacobowitz, Tom Tromey, Pedro Alves (the other people at the front) and the other GDB maintainers and developers in the room.

We nailed down some pending issues that were being discussed in the mailing list at the time regarding Python scripting support (man, it’s so much easier to decide things face to face rather than by e-mail!), and also discussed a bit of reversible debugging, multithreading GDB itself, GDB scalability, what to do regarding the next release (in a nutshell: wait about a year from the last release so that all the cool stuff which is being worked on right now gets in and settle down), moving the bugs database from GNATS to bugzilla (thanks for doing this Tromey!) etc.

Also after the BoF Pedro Alves gave a very good improvised tutorial on the GDB event loop which he has been studying for the past few months. It felt like cheating, to get all that knowledge in what, half an hour? 🙂 Thanks so much Pedro, it was awesome.

And of course all the interaction with the people who were there, like Joel Brobecker (playing tennis is more serious than I thought!), Gaius Mulley (Pink Floyd!), Anmol Paralkar, Ramana Radhakrishnan and many others (I don’t even try to enumerate, just a random sample).

I shared a suite in Ottawa with David Edelsohn and Kenneth Zadeck, which was an interesting thing in itself. Heading back to the hotel felt like going to an extended GCC summit. 🙂 I almost learned something about GCC internals (SSA, LTO, register allocation) and also had very interesting conversations in general.

And of course my one week of backpacking in Canada after the summit, which was another blast. 🙂

Read Full Post »

Older Posts »