The BSD Debugger

This page contains notes and thoughts about the possibility of replacing the GNU debugger.

See also the BSDdbg SourceForge project here:



This section is used to collect notes about basic functionality we expect the debugger to have, as well as more advanced features. Its purpose is to draw the landscape of what should and could be, so as to have an indication of the extend of the work and the potential complexities we may need to have to deal with. This helps us to come up with a better design.

Basic functionality

The debugger needs to support kernel debugging as well as user space debugging. Both kernel and user space debugging requires the support for:

Advanced features


The following sections describe the components or basic building blocks that a debugger can make use of.

ELF (libelf)

The fundamental file format is ELF. It's used for executables, shared libraries, kernel, modules and core files for both user space and kernel. At this time only sparc64 does not use ELF based kernel core dumps, normalizing on ELF means that sparc64 needs to change kernel core file formats. It also means that platforms that don't support kernel core files should implement them as ELF files. Note that amd64 uses relocatable object files as modules. While these are ELF, relocatable object files are not designed to be used as load modules. This probably needs special treatment.

The ElfToolChain project has created a BSD licensed libelf implementation.

DWARF (libdwarf)

Source level debugging requires debug information to be present that maps raw machine-level entities to source-level definitions and declarations. The de facto standard for this is DWARF. It is expected that significant work is required to do the source correlation. A BSD licensed DWARF library would be ideal, but lacking that a LGPL library should be a good solution to start off with.

Sean Farley pointed me to:

Unwinding (libunwind)

Disassembly of machine code (libdisasm)

Use an API that is based on VLIW hardware. Scalar or superscalar processors are just a special case of which the number of operations per instruction is 1. Therefore, disassembly of an instruction at a given address can return something like the following:

The API needs callback functions so that the disassembler can fetch the instruction bytes as well as possibly obtain register contents. For this it seems logical to use the proc_services API.

disasm API:

User interface

The following sections collect thoughts about a user interface and the set of commands the user may want to see implemented. This covers both basic functionality as well as advanced features.


While debugging, the user may want to view (inspect) any of the following:


While debugging, the user may want to perform any of the following actions:

See also

TheBsdDebugger (last edited 2009-06-27 18:47:37 by MarcelMoolenaar)