From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1FZ8Xu-0002xH-EJ for qemu-devel@nongnu.org; Thu, 27 Apr 2006 11:36:46 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1FZ8Xt-0002wy-LH for qemu-devel@nongnu.org; Thu, 27 Apr 2006 11:36:46 -0400 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1FZ8Xt-0002wu-Fp for qemu-devel@nongnu.org; Thu, 27 Apr 2006 11:36:45 -0400 Received: from [147.11.1.11] (helo=mail.wrs.com) by monty-python.gnu.org with esmtp (Exim 4.52) id 1FZ8ap-0000bg-DN for qemu-devel@nongnu.org; Thu, 27 Apr 2006 11:39:47 -0400 Received: from ALA-MAIL03.corp.ad.wrs.com (ala-mail03 [147.11.57.144]) by mail.wrs.com (8.13.6/8.13.3) with ESMTP id k3RFai8Y015256 for ; Thu, 27 Apr 2006 08:36:44 -0700 (PDT) Message-ID: <4450E50B.4040201@windriver.com> Date: Thu, 27 Apr 2006 10:36:43 -0500 From: Jason Wessel MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [Qemu-devel] Strange page fault problem in qemu-system-arm Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org 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 [] (show_regs+0x0/0x50) from [] (__do_user_fault+0x5c/0xa4) r4 = C6080580 [] (__do_user_fault+0x0/0xa4) from [] (do_page_fault+0x1e4/0x214) r7 = C001B480 r6 = C6080580 r5 = C0454A70 r4 = FFFFFFEC [] (do_page_fault+0x0/0x214) from [] (do_DataAbort+0x3c/0xa4) [] (do_DataAbort+0x0/0xa4) from [] (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 [] (show_regs+0x0/0x50) from [] (__do_user_fault+0x5c/0xa4) r4 = C6080580 [] (__do_user_fault+0x0/0xa4) from [] (do_page_fault+0x1e4/0x214) r7 = C001B480 r6 = C6080580 r5 = C0454A70 r4 = FFFFFFEC [] (do_page_fault+0x0/0x214) from [] (do_DataAbort+0x3c/0xa4) [] (do_DataAbort+0x0/0xa4) from [] (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.