{"id":124,"date":"2011-02-22T17:29:15","date_gmt":"2011-02-23T01:29:15","guid":{"rendered":"http:\/\/blog.mozilla.org\/sfink\/?p=124"},"modified":"2021-06-13T14:08:58","modified_gmt":"2021-06-13T21:08:58","slug":"fun-with-gdb","status":"publish","type":"post","link":"https:\/\/blog.mozilla.org\/sfink\/2011\/02\/22\/fun-with-gdb\/","title":{"rendered":"Fun and Games With gdb"},"content":{"rendered":"

As with most developers, I have a love\/hate relationship with gdb, and have built up a clunky set of tips, tricks, and workarounds that I commonly use. I thought I’d share some of mine here, in a typically disorganized fashion:<\/p>\n

Breakpoint Command Lists<\/strong><\/p>\n

This may be well known to everyone but me, but gdb lets you run arbitrary canned expressions every time a breakpoint is hit. This is incredibly useful when you need to know the last time something changed before a crash or some other detectable event. The usual problem is that if you set a breakpoint or watchpoint or whatever, you’ll hit it over and over again before the “interesting” one happens, and it’ll take way too long and you’ll give up in disgust. So instead, try something like this:<\/p>\n

  (gdb) b somefilename.cpp:1234\r\n  Breakpoint 2 at ...\r\n  (gdb) command 2\r\n  > bt\r\n  > cont\r\n  > end\r\n  (gdb) cont\r\n<\/pre>\n
Now, gdb will run normally, except whenever that breakpoint is hit it’ll dump out the full stack and then continue. When you crash or hit your other breakpoint or whatever, you can look backwards to the previous time you hit breakpoint 2 (hardware watchpoints are especially good with this) and see what the stack was then. If the breakpoint is hitting a lot, this may not be fast, but you can leave it running unattended all night if you have to.<\/p>\n
I’ve tried getting clever with this, with mixed results: once, I wanted to know when a particular value changed. I could set a hardware watchpoint, but it was constantly getting changed by a function f() that I didn’t care about. It was some other mysterious source of mutation that was tripping me up. So I set the hardware watchpoint, and then set breakpoints on the beginning and end of f(). I then created a command list for the breakpoint on the start of f() that disabled the watchpoint and continued, and a command list for the breakpoint on the end of f() to re-enable the watchpoint.<\/p>\n
Unfortunately, it didn’t work. I still don’t know why. Maybe there’s something weird about watchpoints. I didn’t have time to dig into it then. But you get the idea. (Hmm… if it was having trouble with enable\/disable, perhaps I should have set and cleared a convenience variable $active and made the watchpoint conditional on that…)<\/p>\n
Logging From gdb<\/strong><\/p>\n
Occasionally, I have some big wad of data that needs to be interpreted by a different program. Let’s say it’s in a char* variable with its length stored in another variable. My usual approach is to print out the contents using the ‘x’ or ‘p *foo @ 100’ or whatever, then use emacs or Perl to unescape. But for large wads of data, this is unworkable. (For example, I’ve done this with entire images.)<\/p>\n
So write it out to a file instead:<\/p>\n
  (gdb) p creat(\"\/tmp\/somefile.dat\", 0777)\r\n  $26 = 37\r\n  (gdb) p write(37, s, len)\r\n  $27 = 168\r\n  (gdb) p close(37)\r\n  $28 = 0\r\n<\/pre>\n
…and now you have a handy little file containing just your data and nothing else.<\/p>\n
In conjunction with the previous trick, you can append wads of binary data to a trace file every time you hit a breakpoint. Fun!<\/p>\n
Watchpoints<\/strong><\/p>\n
This may be outdated. gdb has a nice watchpoint facility, but it has a tendency to take you too literally — when you ask it to watch a particular expression, it often sets a software<\/em> watchpoint on that expression, meaning it constantly re-evaluates the expression over and over and slows execution down to a crawl. If you know that the various pointers involved aren’t going to change (or if they change, you want the current one anyway), it’s often handy to take the address of the expression you want to watch and then watch the dereference of that:<\/p>\n
\u00a0 (gdb) p &fun->atom\r\n  $27 = (JSAtom **) 0x7fffe3b6b778\r\n  (gdb) watch *$27\r\n  Hardware watchpoint 5: *$27<\/pre>\n
This doesn’t seem to be as necessary as it used to; it seems to do hardware watchpoints automatically in many more cases. But it still complains when the expression is no longer valid.<\/p>\n
I notice (while writing this) that there is now a -l option for doing something like this automatically. I’ve never tried it, but it sounds like it’d do what I want.<\/p>\n
Automagical debugging<\/strong><\/p>\n
I nearly always run gdb within emacs so it automatically loads and highlights the current line of code for me (and gives history, etc.) But say I want to run<\/p>\n
  myprog -s -t lamppost -- monkey walrus -teeth-<\/pre>\n
I have to:<\/p>\n