[Qemu-devel] Re: ARM ethernet fixes

[Antti P Miettinen]

Daniel Jacobowitz <address@hidden> 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/