OpenBSD Journal

g2k16 Hackathon Report: Jasper Lievisse Adriaanse on ddb(4) and more

Contributed by rueda on from the out-with-the-old-and-in-with-the-new dept.

Next up with a g2k16 Hackathon report is Jasper Lievisse Adriaanse:

Shortly before the hackathon I contacted mpi@ to check up on the status of his Dynamic Profiling (read DTrace) work. This eventually led me to my goal for this hackathon of making a start integrating CTF into our kernel.

First a little bit of background; so a compiler generates DWARF data when compiling an object file with -g. DWARF is used by debuggers to match symbols to line-numbers, for example. CTF (Compact C Type Format) can be considered a subset of DWARF that only records the types and function prototypes that are present in an object file. The data is compressed and stored in the .SUNW_ctf section of ELF files. This greatly compacts the space used and makes it feasible to keep CTF data for all binaries (whereas you wouldn't want to retain all DWARF data unless you're actually going to debug something). While DTrace could use CTF to gain knowledge of types, my initial goal was to get started integrating it into ddb(4).

So the first task would be to port the original CDDL-licensed tools which could be used as a baseline against which BSD-licensed tools could be compared and tested.

There are essentially two versions of the CTF tools, the original illumos tools and the recently improved tools by Joyent. I initially started to port those from Joyent, however there were too many Solaris-specifics that porting those would be too much of a task to be worth it. FreeBSD uses the illumos versions and they even had a build framework for them, so I ended up porting those.

These tools work by first converting the DWARF data into CTF, inserting it back into the object file in a new .SUNW_ctf section and finally merging all object files' CTF sections into the executable binary. This last step is quite an expensive operation as all the symbols have to be merged and resolved. After some initial struggles to find the right way of integrating them into the kernel build I had a bsd.ctf fully annotated and ready to do...well, nothing really. It's one thing to dump the functions and types "offline" (i.e. operating on the binary file) compared to inspecting the running kernel's CTF data. mpi@ had already written a ctfdump(1) tool to dump and inspect the CTF section and this greatly helped me get started in ddb(4).

The net result of spending a week in ddb(4) is that on a CTF-enabled kernel we can now correctly print the number of arguments for a function when invoking trace from within ddb. Previously it would blindly return 0 arguments (on amd64/i386 at least) but now the CTF section is consulted to lookup the function prototype instead. While it's a humble beginning and the code isn't committed yet (it'll be hidden behind a DDBCTF kernel option for the time being), it does provide a way to expand CTF usage by ddb(4) and eventually DTrace. However that's still a long way to go.

Besides hacking ddb I *finally* removed gtk+1 and xmms. While they served their purpose, they had been rotting away for many a solstice (almost 16 years since x11/gtk+ was updated)...Antoine had the honor of putting glib1 out the pasture. Lastly I prepared the puppet ports for handing over maintainership to sebastia@ after rpe@ suggested I'd be the better maintainer for ansible nowadays.

Many thanks to the OpenBSD Foundation, avsm@ and Gemma for organizing a terrific hackathon in the William Gates building!

Thanks, Jasper, for this fascinating report.

(Comments are closed)

  1. By Amit Kulkarni ( on

    Holy cow guys, OpenBSD is going to capture the market slowly but surely! Superb work if DTrace like capabilities get into the kernel land, and be able to be used by users.


Copyright © - Daniel Hartmeier. All rights reserved. Articles and comments are copyright their respective authors, submission implies license to publish on this web site. Contents of the archive prior to as well as images and HTML templates were copied from the fabulous original with Jose's and Jim's kind permission. This journal runs as CGI with httpd(8) on OpenBSD, the source code is BSD licensed. undeadly \Un*dead"ly\, a. Not subject to death; immortal. [Obs.]