martin.schroeder at openlimit.com
Mon Nov 24 16:17:43 CET 2014
Am 22.11.2014 um 15:37 schrieb ba_f:
> well i guess we're stuck here.
> Because i can't find no 15c7a8 nor e12fff37 in myClient.
> I also checked the one shared lib myClient uses, without success.
> Maybe i do objdump the wrong files?
> arm-linux-gnueabihf-objdump -Dlx l4re-snapshot-2014022818/obj/l4/arm-ca/bin/arm_armv7a/l4f/myClient | less
> arm-linux-gnueabihf-objdump -Dlx l4re-snapshot-2014022818/obj/l4/arm-ca/lib/arm_armv7a/l4f/libClient.so | less
> But hey, JDB tells me that at 15c7a8 there is the instruction e12fff37 <=> blx r7.
> And this is exactly what i get when objdump moe. PC and opcode match.
> objdump -Dlx l4re-snapshot-2014022818/obj/l4/arm-ca/bin/arm_armv7a/l4f/moe | less
> 15c7a8: e12fff37 blx r7
> Sounds logic to me, that BOEHM_GC runs into the fault...
blx r7 is a false alarm, it cannot cause this type of write page fault. Even the instruction itself makes no sense since r7 has a
value of 1.
Could you do the following: Insert a known write page fault into your client (maybe something like *(volatile int *)0x0=0xaffedead;
) and search for the pc in "objdump -d" on myClient. You can do the same with myServer. This should match and you will see opcode
causing the write page fault.
Now enter JDB and dump the instruction @pc. This does not match the opcode caused the write page fault. Check the last line of the
dump screen and you will see the reason: "dump: d<010001fc> physical".
More information about the l4-hackers