Hello,
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 directory.
I have found this in moe: GC_try_to_collect_inner(): /src/l4/pkg/boehm_gc/contrib/alloc.c:404 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!
ba_f