From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12369 invoked by alias); 14 Sep 2011 16:21:42 -0000 Received: (qmail 12359 invoked by uid 22791); 14 Sep 2011 16:21:38 -0000 X-SWARE-Spam-Status: No, hits=-0.5 required=5.0 tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,FREEMAIL_ENVFROM_END_DIGIT,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,TW_BL,T_TO_NO_BRKTS_FREEMAIL X-Spam-Check-By: sourceware.org Received: from mail-ew0-f42.google.com (HELO mail-ew0-f42.google.com) (209.85.215.42) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 14 Sep 2011 16:21:23 +0000 Received: by ewy2 with SMTP id 2so1278356ewy.15 for ; Wed, 14 Sep 2011 09:21:22 -0700 (PDT) MIME-Version: 1.0 Received: by 10.213.113.13 with SMTP id y13mr800150ebp.88.1316017282012; Wed, 14 Sep 2011 09:21:22 -0700 (PDT) Received: by 10.213.16.201 with HTTP; Wed, 14 Sep 2011 09:21:21 -0700 (PDT) Date: Wed, 14 Sep 2011 16:21:00 -0000 Message-ID: Subject: GDB 7.2 gets SIGSEGV when step into a function in a shared library From: Liang Cheng To: gdb@sourceware.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2011-09/txt/msg00045.txt.bz2 Hi, The application and library under debug were built for ARM. The target is running Android OS, and the host is Linux X86 64. As long as we try to step into the function xa_fun_in_lib, it would cause segmentation fault in gdb. Same thing happened if step the instructio= ns. Here are the experiments I did for this issue, and some notes. 0/. Apparently the app is built into ARM instruction, and the lib is built into Thumb instruction. 1/. The symbols of xa_fun_in_lib is good. 2./ If I set breakpoint at xa_fun_in_lib, I would be able to step into the function once the breakpoint is hit. 3/. In order to see which address it tries to access, I manually changed the vPacket to use 's', and stepped the instruction " 0x8630: ldr pc, [r12, #2820]! ; 0xb04". Also I added some instrumentation code in gdbserver side linux_low.c::linux_resume_one_lwp, as follows: ptrace(PTRACE_GETREGS, lwpid_of(lwp), 0, (void *)&tmpBuf); ptrace (step ? PTRACE_SINGLESTEP : PTRACE_CONT, lwpid_of (lwp), 0, /* Coerce to a uintptr_t first to avoid potential gcc warning of coercing an 8 byte integer to a 4 byte pointer. */ (PTRACE_ARG4_TYPE) (uintptr_t) signal); retVal =3D ptrace(PTRACE_GETREGS, lwpid_of(lwp), 0, (void *)&tmpBuf); Before ptrace(SINGLESTEP/CONT..) is called, (gdb) x /32x &tmpBuf 0xbed9c8d0: 0x0000000a 0x80009a04 0x00000000 0x00000000 0xbed9c8e0: 0xbeaf6c58 0x00008d9c 0x00000001 0xbeaf6c40 0xbed9c8f0: 0x00000000 0x00000000 0x00000000 0x00000000 0xbed9c900: 0x00008630 0xbeaf6c38 0x00008d21 0x00008630 <---------this is the PC after it is called, (gdb) x /32x &tmpBuf 0xbed9c8d0: 0x0000000a 0x80009a04 0x00000000 0x00000000 0xbed9c8e0: 0xbeaf6c58 0x00008d9c 0x00000001 0xbeaf6c40 0xbed9c8f0: 0x00000000 0x00000000 0x00000000 0x00000000 0xbed9c900: 0x00009134 0xbeaf6c38 0x80003701 0x80483702 <---------this is the PC It looks like PC gets messed up when executing the instruction at 0x8630. I don't know this happens, or whether in this case registers dump are valid. 4/. If both app and library are built with ARM flag, which means both app and lib would use ARM instruction, I am not able step into the function too although 'step' does not cause segmentation fault. In this case, if I manipulate the vPacket (sent to gdbserver on target) to use 's' instead of 'c', it would be able to step into the function. So far I am stuck because of no idea why PC gets messed up. Anyone else the similar issue when trying to debug function in library? And any input to how to investigate gdb/gdbserver side also is appreciated. (below some other information is dumped). thanks Liang (gdb) disassemble /m 0x8d14 Dump of assembler code for function main: .... 286 =A0 =A0 =A0 =A0 z =3D xa_fun_in_lib(10); =3D> 0x00008d18 <+84>: =A0 =A0mov.w =A0 r0, #10 =A0 0x00008d1c <+88>: =A0 =A0blx =A0 =A0 0x8628 =A0 0x00008d20 <+92>: =A0 =A0mov =A0 =A0 r3, r0 =A0 0x00008d22 <+94>: =A0 =A0str =A0 =A0 r3, [r7, #44] =A0 ; 0x2c (gdb) x /8i 0x8628 =3D> 0x8628: add r12, pc, #0 0x862c: add r12, r12, #0 0x8630: ldr pc, [r12, #2820]! ; 0xb04 <=3D=3D=3D=3D=3D=3D This line seems to cause the issue. 0x8634: andeq r0, r0, r0 (gdb) info register .... sp 0xbee1fc48 0xbee1fc48 lr 0x8d21 36129 pc 0x8628 0x8628 cpsr 0x60000010 1610612752 (gdb) x /8xdwx 0x8630+0xb04 0x9134 <_GLOBAL_OFFSET_TABLE_+32>: 0x800036fd 0x00000000 0x00000000 0x00000000 0x9144 <__dso_handle+4>: 0x00000000 0x00000000 0x00000000 0x00000000 (gdb) info address xa_fun_in_lib Symbol "xa_fun_in_lib(int)" is a function at address 0x800036fc. (gdb) l xa_fun_in_lib 212 } 213 } 214 215 216 int xa_fun_in_lib(int x) 217 { 218 int y =3D 0; 219 int z =3D 3; 220 221 z =3D x + y + z*8; (gdb) l 222 return z; 223 } (gdb) x /32i 0x800036fc 0x800036fc : push {r7} 0x800036fe : sub sp, #20 0x80003700 : add r7, sp, #0 0x80003702 : str r0, [r7, #4] 0x80003704 : mov.w r3, #0 0x80003708 : str r3, [r7, #12] 0x8000370a : mov.w r3, #3 0x8000370e : str r3, [r7, #8] 0x80003710 : ldr r2, [r7, #4] 0x80003712 : ldr r3, [r7, #12] 0x80003714 : adds r2, r2, r3 0x80003716 : ldr r3, [r7, #8] 0x80003718 : mov.w r3, r3, lsl #3 0x8000371c : adds r3, r2, r3 0x8000371e : str r3, [r7, #8] 0x80003720 : ldr r3, [r7, #8] 0x80003722 : mov r0, r3 0x80003724 : add.w r7, r7, #20 0x80003728 : mov sp, r7 0x8000372a : pop {r7} 0x8000372c : bx lr 0x8000372e: nop