[Qemu-devel] Re: ARM ethernet fixes

[Antti P Miettinen <ananaza@iki.fi>]

Daniel Jacobowitz <drow@false.org> writes:
> It appears to work fairly well.

I can confirm that. I'm currently debugging a segmentation fault in
compiling one source file of firefox. Something that the current ARM
sysemu can do is e.g.
- boot debian/sid NFS root
- compile gcc far enough to produce a cc1plus with debug info
- run gdb inside emacs to debug cc1plus compiling a ff source file
- run cc1plus under gdb with a breakpoint with ignorecount
- be debugged with arm-linux-gdb

IMHO, thats quite impressive :-)

Might as well describe the thing I'm trying to debug. Dunno what the
exact problem is but it is repeatable. The complete test case is a bit
large, but the segfaulting code qestion looks like:

(gdb) disas $pc-16 $pc+16
Dump of assembler code from 0x31bdac to 0x31bdcc:
0x0031bdac <global_alloc+1016>:	ldr	r1, [r2, #28]
0x0031bdb0 <global_alloc+1020>:	add	r3, r3, r1
0x0031bdb4 <global_alloc+1024>:	str	r3, [r4, #8]
0x0031bdb8 <global_alloc+1028>:	add	r1, r4, #12	; 0xc
0x0031bdbc <global_alloc+1032>:	ldmia	r1, {r1, lr}
0x0031bdc0 <global_alloc+1036>:	ldr	r3, [r0, #16]
0x0031bdc4 <global_alloc+1040>:	ldr	r2, [r3, #32]
0x0031bdc8 <global_alloc+1044>:	add	r1, r1, r2
End of assembler dump.

And the registers before SIGSEGV look like:

(gdb) info reg
r0             0x58ff48	5832520
r1             0x4205effc	1107685372
r2             0x41fc7320	1107063584
r3             0x0	0
r4             0x4205eff0	1107685360
r5             0x29e	670
r6             0x42059008	1107660808
r7             0x5d0ab0	6097584
r8             0x3ba8ea	3909866
r9             0x43d9e8	4446696
r10            0x1	1
r11            0x3ecd20	4115744
r12            0xc	12
sp             0xbef3b234	-1091325388
lr             0x2	2
pc             0x31bdbc	3259836
fps            0x1001010	16781328
cpsr           0x10	16

So it looks like we are about to load a couple of longs from
0x4205effc. But when I step:

(gdb) si

Program received signal SIGSEGV, Segmentation fault.
0x0031bdbc in global_alloc (file=0x0) at ../../src/gcc/global.c:490

Looks like the kernel somehow ends up thinking that we are loading
something from zero. Hmm.. the value being loaded to r1 is zero. So
could this be related to crossing a page boundary in the middle of an
instruction? But anyway - I'll try to debug this further..

-- 
http://www.iki.fi/~ananaza/