Screen Version

Debugging SOS

When developing an operating system on top of seL4 you do not have the luxury of using a debugger such as gdb. Your best bet is a combination of dprintf and objdump.

Using objdump

Whenever you cause a fault, you should be able to see the current program counter printed out. You can use objdump to find where the offending code is. Say we saw the following error message:

   sos_server: sel4sos faulted at 0x00000000, pc = 0x000089dc, fsr = 0x00000007, Data fault
   Debug halt syscall from user thread 0xf0063700

The first hex number is the address that the fault occured on. Pc is the program counter, and fsr is the fault status register. From this we can see that the offending instruction is at 89dc. By looking up the fsr in the ARMv5 manual, we can tell that it is a page translation fault, which is expected as the fault address is NULL.

% armeb-oe-linux-gnueabi-objdump -Dlx stage/arm/nslu2/bin/sos  | less

You can now use the searching facility in less to search for the faulting address. In this case I find the following fragment of output:

   /fscratch/alyons/aos-2011/apps/sos/src/main.c:200
    89d4:       e3a07000        mov     r7, #0
    89d8:       e3a03004        mov     r3, #4
    89dc:       e5873000        str     r3, [r7]

We can see that the error has occured on code at line 200 of main.c. Reading the assembly directly (something you should work on), we can see that I've tried to write '4' to address '0', which caused the fault.

More on objdump

objdump is a very handy utility for working out exactly what is where in an executable so you can work out what exactly is going wrong.

The two standard incantations for objdump are:

and

The first command (-dl) disassesmbles the text segment and shows you all the instructions and at what address. Using this information you can find out things such as:

• What does my function compile to?

  eg. Am I compiling the right function? Do the instructions make sense?

• Why is this instruction crashing?

  Look at the fsr for the type of fault, and use objdump to find the exact instruction causing the fault.

NB: In case it's not yet obvious, you will need to get up to speed on your ARM assembly and not be afraid to get your hands dirty if you want to minimise the time you spend debugging.

The second objdump command (-lx) is useful for when addresses appear inside an object file but outside of the text segment. This is especially useful when debugging ELF loading. The -lx option displays section and symbol information. Further options can be added to dump data segments etc. man objdump is your friend.