arm32 is broken

[Martin Decky]

After moving to GCC 4.4.1, the arm32 port seems to be broken when running in GXemul. An assert on line 118 in generic/src/mm/page.c (in page_mapping_insert()) gets hit while mapping kernel memory in page_arch_init().

This seems to be some kind of memory corruption or misbehaving exception handler, since several page_mapping_insert() calls execute succesfully before this happens.

[Jakub Jermář]

I finally built a cross gdb
for arm32 so that now I am able to set a watchpoint on page_mapping_operations.
I now see that frame_alloc() in pt_mapping_insert() is returning a frame, which
is in the kernel data region and coincides with the frame where page_mapping_operations
lives. This memory gets cleared by memsetb() called from pt_mapping_insert()
and thus we hit the assertion:

(gdb) break page_arch_init
Breakpoint 2 at 0x802013bc
(gdb) c
Continuing.

Breakpoint 2, 0x802013bc in page_arch_init ()
(gdb) disassemble
Dump of assembler code for function page_arch_init:
0x802013bc <page_arch_init+0>:	push	{r4, r5, r6, lr}
0x802013c0 <page_arch_init+4>:	ldr	r6, [pc, #128]	; 0x80201448 <page_arch_init+140>
0x802013c4 <page_arch_init+8>:	ldr	r3, [r6]
0x802013c8 <page_arch_init+12>:	ldr	r2, [pc, #124]	; 0x8020144c <page_arch_init+144>
0x802013cc <page_arch_init+16>:	cmp	r3, #0	; 0x0
0x802013d0 <page_arch_init+20>:	ldr	r3, [pc, #120]	; 0x80201450 <page_arch_init+148>
0x802013d4 <page_arch_init+24>:	ldreq	r5, [pc, #120]	; 0x80201454 <page_arch_init+152>
0x802013d8 <page_arch_init+28>:	str	r2, [r3]        ; page_mapping_operations assignment
...
(gdb) si
0x802013c0 in page_arch_init ()
(gdb) si
0x802013c4 in page_arch_init ()
(gdb) 
0x802013c8 in page_arch_init ()
(gdb) 
0x802013cc in page_arch_init ()
(gdb) 
0x802013d0 in page_arch_init ()
(gdb) 
0x802013d4 in page_arch_init ()
(gdb) 
0x802013d8 in page_arch_init ()
...
(gdb) printf "%x\n", &page_mapping_operations
80242a5c
(gdb) printf "%x\n", page_mapping_operations
8022a04c
(gdb) printf "%x\n", &pt_mapping_operations
8022a04c
(gdb) watch page_mapping_operations
Hardware watchpoint 3: {<data variable, no debug info>} 2149853788
(gdb) c
Continuing.
Hardware watchpoint 3: {<data variable, no debug info>} 2149853788

Old value = -2145214388
New value = 0
0x802174b0 in _memsetb ()
(gdb) bt
#0  0x802174b0 in _memsetb ()
#1  0x802021d0 in pt_mapping_insert ()
#2  0x80211958 in page_mapping_insert ()
#3  0x802013fc in page_arch_init ()
#4  0x8020c090 in main_bsp_separated_stack ()
#5  0x8020c054 in main_bsp ()
Backtrace stopped: frame did not save the PC
(gdb) info registers
r0             0x80242000	2149851136     ; <======= frame to be zeroed
r1             0x1000	4096
r2             0x0	0
...
(gdb) printf "%x\n", page_mapping_operations
0
(gdb) printf "%x\n", &page_mapping_operations
80242a5c

So the question now is, why is physical address 0x80242000 available
for allocation when it contains kernel data?

And then we should ask why we are not seeing the same problem with
the old toolchain.

[Jakub Jermář]

Fix merged in head,73.