From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2657 invoked by alias); 15 Sep 2011 05:46:20 -0000 Received: (qmail 2641 invoked by uid 22791); 15 Sep 2011 05:46:19 -0000 X-SWARE-Spam-Status: No, hits=-2.1 required=5.0 tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,TW_BL X-Spam-Check-By: sourceware.org Received: from mail-fx0-f41.google.com (HELO mail-fx0-f41.google.com) (209.85.161.41) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 15 Sep 2011 05:46:02 +0000 Received: by fxh17 with SMTP id 17so321092fxh.0 for ; Wed, 14 Sep 2011 22:46:01 -0700 (PDT) Received: by 10.223.22.150 with SMTP id n22mr1138343fab.110.1316065561097; Wed, 14 Sep 2011 22:46:01 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.112.68 with HTTP; Wed, 14 Sep 2011 22:45:21 -0700 (PDT) In-Reply-To: References: From: Hui Zhu Date: Thu, 15 Sep 2011 05:46:00 -0000 Message-ID: Subject: Re: GDB 7.2 gets SIGSEGV when step into a function in a shared library To: Liang Cheng Cc: 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/msg00050.txt.bz2 Try the trunk. If you got trouble with built trunk. Try https://code.google.com/p/gdbt/ Thanks, Hui On Thu, Sep 15, 2011 at 00:21, Liang Cheng wrote: > Hi, > > The application and library under debug were built for ARM. =A0The > target is running Android OS, > and the host is Linux X86 64. =A0As 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 instruct= ions. > > 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, =A0I manually > changed the vPacket to use 's', > and stepped the instruction " 0x8630: =A0 =A0 =A0ldr =A0 =A0 pc, [r12, #2= 820]! > =A0 =A0; 0xb04". Also I added > some instrumentation code in gdbserver side > linux_low.c::linux_resume_one_lwp, as follows: > > =A0 =A0 ptrace(PTRACE_GETREGS, lwpid_of(lwp), 0, (void *)&tmpBuf); > =A0 =A0 ptrace (step ? PTRACE_SINGLESTEP : PTRACE_CONT, lwpid_of (lwp), 0, > =A0 =A0 =A0/* Coerce to a uintptr_t first to avoid potential gcc warning > =A0 =A0 =A0 =A0 of coercing an 8 byte integer to a 4 byte pointer. =A0*/ > =A0 =A0 =A0(PTRACE_ARG4_TYPE) (uintptr_t) signal); > > =A0 =A0 =A0retVal =3D ptrace(PTRACE_GETREGS, lwpid_of(lwp), 0, (void *)&t= mpBuf); > > Before ptrace(SINGLESTEP/CONT..) is called, > (gdb) x /32x &tmpBuf > 0xbed9c8d0: =A0 =A0 0x0000000a =A0 =A0 =A00x80009a04 =A0 =A0 =A00x0000000= 0 =A0 =A0 =A00x00000000 > 0xbed9c8e0: =A0 =A0 0xbeaf6c58 =A0 =A0 =A00x00008d9c =A0 =A0 =A00x0000000= 1 =A0 =A0 =A00xbeaf6c40 > 0xbed9c8f0: =A0 =A0 0x00000000 =A0 =A0 =A00x00000000 =A0 =A0 =A00x0000000= 0 =A0 =A0 =A00x00000000 > 0xbed9c900: =A0 =A0 0x00008630 =A0 =A0 =A00xbeaf6c38 =A0 =A0 =A00x00008d21 > 0x00008630 <---------this is the PC > > after it is called, > (gdb) x /32x &tmpBuf > 0xbed9c8d0: =A0 =A0 0x0000000a =A0 =A0 =A00x80009a04 =A0 =A0 =A00x0000000= 0 =A0 =A0 =A00x00000000 > 0xbed9c8e0: =A0 =A0 0xbeaf6c58 =A0 =A0 =A00x00008d9c =A0 =A0 =A00x0000000= 1 =A0 =A0 =A00xbeaf6c40 > 0xbed9c8f0: =A0 =A0 0x00000000 =A0 =A0 =A00x00000000 =A0 =A0 =A00x0000000= 0 =A0 =A0 =A00x00000000 > 0xbed9c900: =A0 =A0 0x00009134 =A0 =A0 =A00xbeaf6c38 =A0 =A0 =A00x80003701 > 0x80483702 =A0<---------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? =A0And any input to how to > investigate gdb/gdbserver side > also is appreciated. =A0(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: =A0 =A0 =A0add =A0 =A0 r12, pc, #0 > =A0 0x862c: =A0 =A0 =A0add =A0 =A0 r12, r12, #0 > =A0 0x8630: =A0 =A0 =A0ldr =A0 =A0 pc, [r12, #2820]! =A0 =A0 =A0 ; 0xb04 > <=3D=3D=3D=3D=3D=3D This line seems to cause the issue. > =A0 0x8634: =A0 =A0 =A0andeq =A0 r0, r0, r0 > (gdb) info register > .... > sp =A0 =A0 =A0 =A0 =A0 =A0 0xbee1fc48 =A0 =A0 =A0 0xbee1fc48 > lr =A0 =A0 =A0 =A0 =A0 =A0 0x8d21 =A0 36129 > pc =A0 =A0 =A0 =A0 =A0 =A0 0x8628 =A0 0x8628 > cpsr =A0 =A0 =A0 =A0 =A0 0x60000010 =A0 =A0 =A0 1610612752 > > (gdb) x /8xdwx 0x8630+0xb04 > 0x9134 <_GLOBAL_OFFSET_TABLE_+32>: =A0 =A0 =A00x800036fd =A0 =A0 =A00x000= 00000 > =A00x00000000 =A0 =A0 =A00x00000000 > 0x9144 <__dso_handle+4>: =A0 =A0 =A0 =A00x00000000 =A0 =A0 =A00x00000000 > 0x00000000 =A0 =A0 =A00x00000000 > > (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 =A0 =A0 =A0 =A0 } > 213 =A0 =A0 } > 214 > 215 > 216 =A0 =A0 int xa_fun_in_lib(int x) > 217 =A0 =A0 { > 218 =A0 =A0 =A0 =A0 int y =3D 0; > 219 =A0 =A0 =A0 =A0 int z =3D 3; > 220 > 221 =A0 =A0 =A0 =A0 z =3D x + y + z*8; > (gdb) l > 222 =A0 =A0 =A0 =A0 return z; > 223 =A0 =A0 } > (gdb) x /32i 0x800036fc > =A0 0x800036fc : =A0 =A0 push =A0 =A0{r7} > =A0 0x800036fe : =A0 sub =A0 =A0 sp, #20 > =A0 0x80003700 : =A0 add =A0 =A0 r7, sp, #0 > =A0 0x80003702 : =A0 str =A0 =A0 r0, [r7, #4] > =A0 0x80003704 : =A0 mov.w =A0 r3, #0 > =A0 0x80003708 : =A0str =A0 =A0 r3, [r7, #12] > =A0 0x8000370a : =A0mov.w =A0 r3, #3 > =A0 0x8000370e : =A0str =A0 =A0 r3, [r7, #8] > =A0 0x80003710 : =A0ldr =A0 =A0 r2, [r7, #4] > =A0 0x80003712 : =A0ldr =A0 =A0 r3, [r7, #12] > =A0 0x80003714 : =A0adds =A0 =A0r2, r2, r3 > =A0 0x80003716 : =A0ldr =A0 =A0 r3, [r7, #8] > =A0 0x80003718 : =A0mov.w =A0 r3, r3, lsl #3 > =A0 0x8000371c : =A0adds =A0 =A0r3, r2, r3 > =A0 0x8000371e : =A0str =A0 =A0 r3, [r7, #8] > =A0 0x80003720 : =A0ldr =A0 =A0 r3, [r7, #8] > =A0 0x80003722 : =A0mov =A0 =A0 r0, r3 > =A0 0x80003724 : =A0add.w =A0 r7, r7, #20 > =A0 0x80003728 : =A0mov =A0 =A0 sp, r7 > =A0 0x8000372a : =A0pop =A0 =A0 {r7} > =A0 0x8000372c : =A0bx =A0 =A0 =A0lr > =A0 0x8000372e: =A0nop >