strange Bug
Martin Schröder
martin.schroeder at openlimit.com
Tue Nov 25 10:30:58 CET 2014
Am 24.11.2014 um 23:37 schrieb ba_f:
>
> Hi Martin,
>
> thank you, but i'm afraid, i haven't learnt the full lesson, yet.
>
>> Hi ba_f,
>>
>> 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".
>>
>>
>> Martin.
>
>
> All right,
> i inserted the faulty instruction, and the familiar Error Message occurs.
>
> myClient| L4Re[rm]: unhandled write page fault @0 pc=7cddc
>
>
> Now, objdump does not show this PC in myClient or libClient. But as before, the PC is found in moe.
>
> Lesson learnt, this PC is useless for me???
>
>
> Ok back to myClient.
> Since i don't know the PC of *(volatile int *)0x0=0xaffedead; i search for the opcode and found this.
>
> 1fdd4: e30d3ead movw r3, #57005 ; 0xdead
> 1fdd8: e34a3ffe movt r3, #45054 ; 0xaffe
>
> Weird again, i can't find one of this instructions in bootstrap.elf.
>
>
>
> So still, i have no clue, how the PC in the Error Message shall lead me to the faulty instruction.
Can you repeat his with the hello example:
int
main(void)
{
for (;;)
{
puts("Hello World!");
*(volatile int *)0x0=0xaffedead;
sleep(1);
}
}
When I run this in Qemu I get:
MOE: cmdline: moe --init=rom/hello
MOE: Starting: rom/hello
MOE: loading 'rom/hello'
Hello World!
L4Re[rm]: unhandled write page fault at 0x0 pc=0x10001fc
L4Re: unhandled exception: pc=0x10001fc
===
id cpu name pr sp wait to state
1d 0 ----- 2 19 1a rcv_wait,exc_progr
1a 0 #hello ff 19 - rcv_wait
a 0 moe ff 9 - rcv_wait
8 0 sigma0 1 7 - rcv_wait
6 1 ----- 0 1 ready
5 0 ----- 0 1 ready
===
thread : 1d <0xf11a4000> CPU: 0:0 prio: 02
state : 40008 rcv_wait,exc_progr
wait for: 1a polling: rcv descr: 00000000
lcked by: timeout :
cpu time: 13.000 ms timeslice: 2000/-1 �s
pager : [C: 3] D: 1a task : D: 19
exc-hndl: [C: 3] D: 1a UTCB : f11da200/b3000200
vCPU : ---
vCPU : ---
PC=010001fc USP=80007ef8
[0] 0000000d 00000001 00000004 0100952c [4] affedead 00000000 00000001 00000005
[8] 01018014 010001e0 00000005 80007f04 [c] 00000008 01009590 60000010 20000010
===
thread : 1a <0xf11a0000> CPU: 0:0 prio: ff
state : 008 rcv_wait
wait for: --- polling: rcv descr: 00000000
lcked by: timeout :
cpu time: 27.000 ms timeslice: 2000/-1 �s
pager : [C: 5] D: 16 task : D: 19
exc-hndl: [C: 5] D: 16 UTCB : f11da000/b3000000
vCPU : ---
vCPU : ---
PC=b0001e78 USP=b1007d70
[0] 00000000 b3000000 fffff806 04000000 [4] 00000000 b001910c 00000000 fffffc18
[8] b00190e4 00000000 b1007d74 b1007d94 [c] 00000001 b0001e78 fffffff8 60000010
===
objdump -d pkg/hello/server/src/OBJ-arm_armv7a-l4f/hello
010001e0 <main>:
10001e0: e92d4830 push {r4, r5, fp, lr}
10001e4: e30d4ead movw r4, #57005 ; 0xdead
10001e8: e28db00c add fp, sp, #12
10001ec: e34a4ffe movt r4, #45054 ; 0xaffe
10001f0: e3a05000 mov r5, #0
10001f4: e59f0010 ldr r0, [pc, #16] ; 100020c <main+0x2c>
10001f8: eb0024a2 bl 1009488 <puts>
10001fc: e5854000 str r4, [r5]
1000200: e3a00001 mov r0, #1
1000204: eb001f4b bl 1007f38 <sleep>
1000208: eafffff9 b 10001f4 <main+0x14>
100020c: 01012b50 .word 0x01012b50
===
and pc=0x10001fc matches exactly the page fault.
Indeed, I didn't found this in objdump -d bootstrap.elf either.
Martin
More information about the l4-hackers
mailing list