[Qemu-devel] Strange page fault problem in qemu-system-arm

[Jason Wessel <jason.wessel@windriver.com>]

Has anyone seen user land page fault problems where gdb does not work 
with the qemu-system-arm ?

I compile my kernel with CONFIG_DEBUG_USER so as to add a debug hook for 
user land page faults, which you can see in the case of running gdb below.

I ran gdb on /bin/ls just as a simple case, IE:
/ # gdb /bin/ls
(gdb) run
Starting program: /bin/ls
BFD: /lib/ld-linux.so.3: warning: sh_link not set for section `.ARM.exidx'
pgd = c7d20000
[00000000] *pgd=06902031, *pte=00000000, *ppte=00000000

Pid: 211, comm:                   ls
CPU: 0
PC is at 0x4000b584
LR is at 0x40003854
pc : [<4000b584>]    lr : [<40003854>]    Not tainted
sp : bea5b958  ip : 40015508  fp : bea5ba34
r10: 4001d000  r9 : 4001d1f8  r8 : 4001d524
r7 : 000f0005  r6 : 4001d538  r5 : 4001d040  r4 : 00000000
r3 : 00000001  r2 : 00000001  r1 : 400159f0  r0 : 00000000
Flags: nzcv  IRQs on  FIQs on  Mode USER_32  Segment user
Control: 3137  Table: 07D20000  DAC: 00000015
[<c0023578>] (show_regs+0x0/0x50) from [<c002d7f8>] 
(__do_user_fault+0x5c/0xa4)
 r4 = C6080580
[<c002d79c>] (__do_user_fault+0x0/0xa4) from [<c002da90>] 
(do_page_fault+0x1e4/0x214)
 r7 = C001B480  r6 = C6080580  r5 = C0454A70  r4 = FFFFFFEC
[<c002d8ac>] (do_page_fault+0x0/0x214) from [<c002dc0c>] 
(do_DataAbort+0x3c/0xa4)
[<c002dbd0>] (do_DataAbort+0x0/0xa4) from [<c0020088>] 
(ret_from_exception+0x0/0x10)
 r8 = 4001D524  r7 = 000F0005  r6 = 4001D538  r5 = 4001D040
 r4 = FFFFFFFF
BFD: /lib/libgcc_s.so.1: warning: sh_link not set for section `.ARM.exidx'
BFD: /lib/libc.so.6: warning: sh_link not set for section `.ARM.exidx'
BFD: /lib/ld-linux.so.3: warning: sh_link not set for section `.ARM.exidx'
(no debugging symbols found)
BFD: /lib/libgcc_s.so.1: warning: sh_link not set for section `.ARM.exidx'
(no debugging symbols found)
BFD: /lib/libc.so.6: warning: sh_link not set for section `.ARM.exidx'
(no debugging symbols found)
BFD: /lib/ld-linux.so.3: warning: sh_link not set for section `.ARM.exidx'
(no debugging symbols found)
pgd = c7d20000
[00000000] *pgd=06902031, *pte=00000000, *ppte=00000000

Pid: 211, comm:                   ls
CPU: 0
PC is at 0x4000b584
LR is at 0x40003854
pc : [<4000b584>]    lr : [<40003854>]    Not tainted
sp : bea5b958  ip : 40015508  fp : bea5ba34
r10: 4001d000  r9 : 4001d1f8  r8 : 4001d524
r7 : 000f0005  r6 : 4001d538  r5 : 4001d040  r4 : 00000000
r3 : 00000001  r2 : 00000001  r1 : 400159f0  r0 : 00000000
Flags: nzcv  IRQs on  FIQs on  Mode USER_32  Segment user
Control: 3137  Table: 07D20000  DAC: 00000015
[<c0023578>] (show_regs+0x0/0x50) from [<c002d7f8>] 
(__do_user_fault+0x5c/0xa4)
 r4 = C6080580
[<c002d79c>] (__do_user_fault+0x0/0xa4) from [<c002da90>] 
(do_page_fault+0x1e4/0x214)
 r7 = C001B480  r6 = C6080580  r5 = C0454A70  r4 = FFFFFFEC
[<c002d8ac>] (do_page_fault+0x0/0x214) from [<c002dc0c>] 
(do_DataAbort+0x3c/0xa4)
[<c002dbd0>] (do_DataAbort+0x0/0xa4) from [<c0020088>] 
(ret_from_exception+0x0/0x10)
 r8 = 4001D524  r7 = 000F0005  r6 = 4001D538  r5 = 4001D040
 r4 = FFFFFFFF

Program received signal SIGSEGV, Segmentation fault.
0x4000b584 in _dl_debug_state () from /lib/ld-linux.so.3
(gdb) bt
#0  0x4000b584 in _dl_debug_state () from /lib/ld-linux.so.3
#1  0x40003854 in ?? () from /lib/ld-linux.so.3


The same kernel on real hardware seems to be just fine IE:
(gdb) run
Starting program: /bin/ls
BFD: /lib/ld-linux.so.3: warning: sh_link not set for section `.ARM.exidx'
BFD: /lib/libgcc_s.so.1: warning: sh_link not set for section `.ARM.exidx'
BFD: /lib/libc.so.6: warning: sh_link not set for section `.ARM.exidx'
BFD: /lib/ld-linux.so.3: warning: sh_link not set for section `.ARM.exidx'
(no debugging symbols found)
BFD: /lib/libgcc_s.so.1: warning: sh_link not set for section `.ARM.exidx'
(no debugging symbols found)
BFD: /lib/libc.so.6: warning: sh_link not set for section `.ARM.exidx'
(no debugging symbols found)
BFD: /lib/ld-linux.so.3: warning: sh_link not set for section `.ARM.exidx'
(no debugging symbols found)
bin      etc      lib      opt      sbin     usr
boot     home     linuxrc  proc     sys      var
dev      initrd   mnt      root     tmp

Program exited normally.
(gdb)

You can ignore the sh_link errors of course.  If someone has any insight 
it would be appreciated.  I am not too sure about the qemu internals for 
ARM at this point, but I might be learning something soon. It looked to 
me like the fatal miss occurred when gdb planted a breakpoint via 
ptrace() for the shared library hooks, but again it is only a theory at 
this point.

Thanks,
Jason.