ba_f at rbg.informatik.tu-darmstadt.de
Thu Nov 13 23:55:57 CET 2014
> We are looking for an instruction at address 0x15c7a8. Things I would
> check now:
> * If the instruction is not in your program (the one in the build
> directory), is it maybe in another module that gets packed into
> your bootstrap.elf image? You get a list of the packed modules
> when you run make E=.. - the binaries should all be in your build
I have found this in moe:
15c7a8: e12fff37 blx r7
> * At the time of the page fault you end up in the kernel debugger.
> Use 'lp' to see the list of present threads. One of them will be
> the one that is in the debugger now. It should be one of the
> L4Re threads (those have names starting with # in the thread list).
> Which other thread is currently blocking in IPC to the L4Re thread?
> What is this thread's state (command 't<id>')? At what instruction
> is the thread stuck? What binary belongs to this thread?
Do u say JDB starts automatically, when the error occurs?
But typing 'lp <ENTER>' in the UART console, doesn't effect anything.
Do i have to add JDB via modules.list or something?
> * Easy stuff: is your program even executing code in its main()
> function already? How far does the program get before the page
> fault happens?
Yes, it runs for a while.
There are two L4-Task doing a protocol over IPC. Client sends a message
and Server answers. Then Client fails, when perparing his next message
(no ipc-functions involved).
> Btw., are you debugging this on real hardware or in an emulator, such
> as qemu?
Only on real HW: ARMv7 Cortex A9.
Qemu doesn't work on my Debian. The window stays black.
Maybe i'll try on an other Linux.
Have a nice day!
More information about the l4-hackers