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
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
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:
% armv5b-softfloat-linux-objdump -dl my_elf.file | less
% armv5b-softfloat-linux-objdump -lx my_elf.file | less
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
- 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.
Last modified: Wed Aug 06 11:00:11 EST 2008