From: Jason Wessel <jason.wessel@windriver.com>
To: qemu-devel@nongnu.org
Subject: [Qemu-devel] Strange page fault problem in qemu-system-arm
Date: Thu, 27 Apr 2006 10:36:43 -0500 [thread overview]
Message-ID: <4450E50B.4040201@windriver.com> (raw)
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.
reply other threads:[~2006-04-27 15:36 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4450E50B.4040201@windriver.com \
--to=jason.wessel@windriver.com \
--cc=qemu-devel@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).