1. Finding where the bug is
  2. What to do if ddb backtrace doesn't work

This article is going to be a collection of random notes which I have found during my development in kernel. I have found that there are some hints which every developer knows, but there is no documentation where newbie can learn them.

Finding where the bug is

When you get a crash in the kernel you want to translate the address from the backtrace to the line in the source code:

Stopped in pid 496.1 (gdb) at netbsd:breakpoint+0x5: leave

First, you need to find the address of the breakpoint function in the running kernel image with the nm(1) command:

nm netbsd | grep breakpoint

Then add 0x5 to the address, and use addr2line(1) to get the exact line in the kernel source code where you get the crash:

addr2line -g netbsd {sum address}

In gdb(1), this can be achieved with the command info line *(function_name)+0x5.

What to do if ddb backtrace doesn't work

The DDB backtrace command usually doesn't work when the EIP register was set to NULL, e.g. via a bad function pointer. In this case we can get part of the backtrace by using a different approach.

db> show all reg

eip 0 cs 0 eflags 0 esp 0xcb741b70

We need to find which address was set in the ESP register (this is the stack pointer register on i386). When we have our address we need to use

x /Lx 0xcb741b70,20

to print the first 20 addresses from the stack. To easily find the address of the last function you need to look for an address with 0xc0 at the start.

The command x /I c06428fc will then translate the function address to it's name with the symbol table lookup. What to do if gdb cannot backtrace through trap()

Use ('source') .../sys/arch/i386/gdbscripts/stack gdb script and run 'stack'. See also PR 10313. How to rebuild /boot

(This example assumes you are running NetBSD-i386)

* Make sure you have the tools built
* sys/arch/i386/stand/boot and enter $TOOLDIR/bin/nbmake-i386
Add a comment