Recently I had to track down a minor bug in the OpenBSD kernel. I tapped QEMU and GDB as debugging tools for the task, running on Ubuntu 12.04 as the host OS. This combination worked extremely well, so for the record here’s how I set it all up.
OpenBSD comes equipped with two kernel debugging mechanisms: ddb and kgdb. ddb(4) is an in-kernel debugger, enabled by default in the GENERIC kernel, and can be invoked either explicitly from the console or automatically in the event of a panic. It is analogous to the Linux debugger kdb in that it can be used to set breakpoints and examine the stack or register state, but (like kdb) it is not a source-level debugger.
For source debugging there is kgdb(7), which offers the ability to remotely debug the kernel by way of a GDB stub running over a serial port; this is similar to the Linux debugger kgdboc. However, kgdb it is not available in the GENERIC kernel, and it imposes an additional set of configurations and debugger latencies on the user. If your debugging task is amenable to running OpenBSD within a virtual machine, as mine was, then there is an easier and better way…
I love Emacs GDB mode, but I always found it annoying that there is no given key binding (or function which could be directly mapped into a key binding) for switching between the different views given by
gdb-many-windows. The usual window and buffer switching functions are insufficient because the GDB windows are flagged as dedicated (so
switch-buffer refuses to swap them in place), and in the case of the Locals/Registers and Breakpoints/Threads windows, the buffer you want to visit doesn’t necessarily even exist until you click that button.
This went from mildly annoying to a major headache when I needed to run the debugger in a remote Emacs session, over SSH from Mac OS X’s Terminal.app which does not support xterm mouse emulation. So I wrote this
gdb-select-window function and corresponding key bindings to finally get the desired behavior…
Put this in your
init.el and fire up
gdb-many-windows, and then you’ll be able to quickly switch between the GDB windows with the following keyboard shortcuts:
C-c C-g c— comint (GDB command) buffer
C-c C-g l— locals buffer
C-c C-g r— registers buffer
C-c C-g u— source window
C-c C-g s— stack buffer
C-c C-g b— breakpoints buffer
C-c C-g t— threads buffer
Update: Discussion on Hacker News
I ran into a really fun bug at work yesterday, where I discovered that my C program was branching down logically inconsistent code paths. After drinking another cup of coffee and firing up GDB I realized that somehow, a boolean variable in my code was simultaneously testing as both true and not true.
While I cannot reproduce the actual source code here, the effect was that code like
bool p; /* ... */ if ( p ) puts("p is true"); if ( ! p ) puts("p is false");
would produce the output:
p is true p is false
So what’s going on here?
I’ve been getting back into Python lately… I just wrote a small module that provides support for pointfree style programming with a combination of automatic partial function/method application and operator overloading for function composition:
from pointfree import * from operator import add fn = pfmap(len) \ >> pfmap(lambda n: n**2) \ >> pfreduce(add, initial=0) fn(["foo", "barr", "bazzz"]) # == 50
See the overview for a lengthier introduction. You can install the pointfree module from the Python Package Index:
$ pip install pointfree
I just found a great blog post by Martin Kleppmann titled Accounting for Computer Scientists, a succinct introduction to double-entry accounting (although he doesn’t refer to it as such) in terms of basic graph theory:
Eventually I figured it out: basic accounting is just graph theory. The traditional ways of representing financial information hide that structure astonishingly well, but once I had figured out that it was just a graph, it suddenly all made sense.
He goes on to illustrate how a profit-and-loss statement and a balance sheet can be visualized on a simple DAG. Good stuff…