From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30125 invoked by alias); 19 Sep 2011 15:57:28 -0000 Received: (qmail 30115 invoked by uid 22791); 19 Sep 2011 15:57:25 -0000 X-SWARE-Spam-Status: No, hits=-1.0 required=5.0 tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,FREEMAIL_ENVFROM_END_DIGIT,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW X-Spam-Check-By: sourceware.org Received: from mail-ew0-f43.google.com (HELO mail-ew0-f43.google.com) (209.85.215.43) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 19 Sep 2011 15:57:04 +0000 Received: by ewy27 with SMTP id 27so2312686ewy.30 for ; Mon, 19 Sep 2011 08:57:03 -0700 (PDT) MIME-Version: 1.0 Received: by 10.213.21.25 with SMTP id h25mr854832ebb.126.1316447822615; Mon, 19 Sep 2011 08:57:02 -0700 (PDT) Received: by 10.213.15.141 with HTTP; Mon, 19 Sep 2011 08:57:02 -0700 (PDT) In-Reply-To: <4E73F7B7.9070800@codesourcery.com> References: <4E72241F.5060402@codesourcery.com> <4E735536.1000405@codesourcery.com> <4E73F7B7.9070800@codesourcery.com> Date: Mon, 19 Sep 2011 15:57:00 -0000 Message-ID: Subject: Re: GDB 7.2 gets SIGSEGV when step into a function in a shared library From: Liang Cheng To: Yao Qi Cc: gdb@sourceware.org Content-Type: text/plain; charset=UTF-8 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/msg00064.txt.bz2 Oh.. I just put too much focus on gdb server side.. ;) Built a gdb from gdb 7.3.1 source, although it behaves better (no segmentation fault), stepping is still not right yet. (gdb) n 286 z =3D xa_fun_in_lib(10); (gdb) set debug infrun 1 (gdb) show debug infrun Inferior debugging is 1. (gdb) s infrun: clear_proceed_status_thread (Thread 1874.1874) infrun: proceed (addr=3D0xffffffff, signal=3D144, step=3D1) infrun: resume (step=3D1, signal=3D0), trap_expected=3D0 infrun: wait_for_inferior (treat_exec_as_sigtrap=3D0) infrun: target_wait (-1, status) =3D infrun: 1874 [Thread 1874.1874], infrun: status->kind =3D stopped, signal =3D SIGTRAP infrun: infwait_normal_state infrun: TARGET_WAITKIND_STOPPED infrun: stop_pc =3D 0x8d1c infrun: software single step trap for Thread 1874.1874 infrun: stepping inside range [0x8d18-0x8d24] infrun: resume (step=3D1, signal=3D0), trap_expected=3D0 infrun: prepare_to_wait infrun: target_wait (-1, status) =3D infrun: 1874 [Thread 1874.1874], infrun: status->kind =3D stopped, signal =3D SIGTRAP infrun: infwait_normal_state infrun: TARGET_WAITKIND_STOPPED infrun: stop_pc =3D 0x8628 infrun: software single step trap for Thread 1874.1874 infrun: stepped into dynsym resolve code infrun: resume (step=3D1, signal=3D0), trap_expected=3D0 infrun: prepare_to_wait infrun: target_wait (-1, status) =3D infrun: 1874 [Thread 1874.1874], infrun: status->kind =3D stopped, signal =3D SIGTRAP infrun: infwait_normal_state infrun: TARGET_WAITKIND_STOPPED infrun: stop_pc =3D 0x862c infrun: software single step trap for Thread 1874.1874 infrun: stepped into dynsym resolve code infrun: resume (step=3D1, signal=3D0), trap_expected=3D0 infrun: prepare_to_wait infrun: target_wait (-1, status) =3D infrun: 1874 [Thread 1874.1874], infrun: status->kind =3D stopped, signal =3D SIGTRAP infrun: infwait_normal_state infrun: TARGET_WAITKIND_STOPPED infrun: stop_pc =3D 0x8630 infrun: software single step trap for Thread 1874.1874 infrun: stepped into dynsym resolve code infrun: resume (step=3D1, signal=3D0), trap_expected=3D0 infrun: prepare_to_wait infrun: target_wait (-1, status) =3D infrun: 1874 [Thread 1874.1874], infrun: status->kind =3D stopped, signal =3D SIGTRAP infrun: infwait_normal_state infrun: TARGET_WAITKIND_STOPPED infrun: stop_pc =3D 0x8d20 infrun: software single step trap for Thread 1874.1874 infrun: stepping inside range [0x8d18-0x8d24] infrun: resume (step=3D1, signal=3D0), trap_expected=3D0 infrun: prepare_to_wait infrun: target_wait (-1, status) =3D infrun: 1874 [Thread 1874.1874], infrun: status->kind =3D stopped, signal =3D SIGTRAP infrun: infwait_normal_state infrun: TARGET_WAITKIND_STOPPED infrun: stop_pc =3D 0x8d22 infrun: software single step trap for Thread 1874.1874 infrun: stepping inside range [0x8d18-0x8d24] infrun: resume (step=3D1, signal=3D0), trap_expected=3D0 infrun: prepare_to_wait infrun: target_wait (-1, status) =3D infrun: 1874 [Thread 1874.1874], infrun: status->kind =3D stopped, signal =3D SIGTRAP infrun: infwait_normal_state infrun: TARGET_WAITKIND_STOPPED infrun: stop_pc =3D 0x8d24 infrun: software single step trap for Thread 1874.1874 infrun: stepped to a different line infrun: stop_stepping 289 res =3D (*engine)->Realize(engine, XA_BOOLEAN_FALSE); (gdb) display /i $pc 1: x/i $pc =3D> 0x8d24 : ldr r3, [r7, #48] ; 0x30 (gdb) info address xa_fun_in_lib Symbol "xa_fun_in_lib(int)" is a function at address 0x800036fc. On Fri, Sep 16, 2011 at 8:28 PM, Yao Qi wrote: > On 09/17/2011 04:03 AM, Liang Cheng wrote: >> Yao/Hui, >> >> Built a gdbserver based on gdb 7.3.1, =C2=A0and I get the exactly same e= rror. >> The gdb that I used is arm-eabi-4.4.3. >> > > You may misunderstand my point. =C2=A0I suggest that you build recent gdb > instead of gdbserver. =C2=A0AFAICS, this problem is related to gdb, rather > than gdbserver. > > "arm-eabi-4.4.3" is not a right version of gdb. > >> Here is debug output. Next step is to try gdb trunk. > > Please build gdb from gdb trunk. > >> >> Breakpoint 1, main (argc=3D1, argv=3D0xbed00cb4) at vendor/altestavplayb= ack.c:284 >> 284 =C2=A0 =C2=A0 =C2=A0 =C2=A0 CheckErr(res); >> 1: x/i $pc >> =3D> 0x8d12 : =C2=A0 =C2=A0ldr =C2=A0 =C2=A0 r0, [r7, #52] =C2= =A0 ; 0x34 >> (gdb) n >> 286 =C2=A0 =C2=A0 =C2=A0 =C2=A0 z =3D xa_fun_in_lib(10); >> 1: x/i $pc >> =3D> 0x8d18 : =C2=A0 =C2=A0mov.w =C2=A0 r0, #10 >> (gdb) set debug infrun 1 >> (gdb) show debug infrun >> Inferior debugging is 1. >> (gdb) s >> infrun: clear_proceed_status_thread (Thread 746.746) >> infrun: proceed (addr=3D0xffffffff, signal=3D144, step=3D1) >> infrun: resume (step=3D1, signal=3D0), trap_expected=3D0 >> infrun: wait_for_inferior (treat_exec_as_sigtrap=3D0) >> infrun: target_wait (-1, status) =3D >> infrun: =C2=A0 746 [Thread 746.746], >> infrun: =C2=A0 status->kind =3D stopped, signal =3D SIGTRAP >> infrun: infwait_normal_state >> infrun: TARGET_WAITKIND_STOPPED >> infrun: stop_pc =3D 0x8d1c >> infrun: software single step trap for Thread 746.746 >> infrun: stepping inside range [0x8d18-0x8d24] >> infrun: resume (step=3D1, signal=3D0), trap_expected=3D0 >> infrun: prepare_to_wait >> infrun: target_wait (-1, status) =3D >> infrun: =C2=A0 746 [Thread 746.746], >> infrun: =C2=A0 status->kind =3D stopped, signal =3D SIGTRAP >> infrun: infwait_normal_state >> infrun: TARGET_WAITKIND_STOPPED >> infrun: stop_pc =3D 0x8628 >> infrun: software single step trap for Thread 746.746 >> infrun: stepped into dynsym resolve code >> infrun: resume (step=3D1, signal=3D0), trap_expected=3D0 >> infrun: prepare_to_wait >> infrun: target_wait (-1, status) =3D >> infrun: =C2=A0 746 [Thread 746.746], >> infrun: =C2=A0 status->kind =3D stopped, signal =3D SIGTRAP >> infrun: infwait_normal_state >> infrun: TARGET_WAITKIND_STOPPED >> infrun: stop_pc =3D 0x862c >> infrun: software single step trap for Thread 746.746 >> infrun: stepped into dynsym resolve code >> infrun: resume (step=3D1, signal=3D0), trap_expected=3D0 >> infrun: prepare_to_wait >> infrun: target_wait (-1, status) =3D >> infrun: =C2=A0 746 [Thread 746.746], >> infrun: =C2=A0 status->kind =3D stopped, signal =3D SIGTRAP >> infrun: infwait_normal_state >> infrun: TARGET_WAITKIND_STOPPED >> infrun: stop_pc =3D 0x8630 >> infrun: software single step trap for Thread 746.746 >> infrun: stepped into dynsym resolve code >> infrun: resume (step=3D1, signal=3D0), trap_expected=3D0 > > GDB is trying to single step this instruction, > > =C2=A0 0x8630: =C2=A0 =C2=A0 =C2=A0ldr =C2=A0 =C2=A0 pc, [r12, #2820]! = =C2=A0 =C2=A0 =C2=A0 ; 0xb04 > > at this point, GDB will compute the "next pc" of this instruction, and > set breakpoint on that address. =C2=A0GDB 7.2 can (or should) compute the > "next pc" correctly, but may not set single-step breakpoint correctly > for correct execution state. > > Ulrich had a patch to address this issue, which might be the cause of > your problem. > > =C2=A0[rfc, arm] Always use correct execution state for single-step break= points > =C2=A0http://sourceware.org/ml/gdb-patches/2011-03/msg01077.html > > This patch should be in 7.3.1. =C2=A0If my assumption above is correct, u= sing > gdb 7.3.1 or cvs trunk should fix your problem. > >> infrun: prepare_to_wait >> infrun: target_wait (-1, status) =3D >> infrun: =C2=A0 746 [Thread 746.746], >> infrun: =C2=A0 status->kind =3D stopped, signal =3D SIGSEGV >> infrun: infwait_normal_state >> infrun: TARGET_WAITKIND_STOPPED >> infrun: stop_pc =3D 0x8d22 >> infrun: random signal 11 >> >> Program received signal SIGSEGV, Segmentation fault. >> infrun: stop_stepping >> 0x00008d22 in main (argc=3D1, argv=3D0xbed00cb4) at vendor/altestavplayb= ack.c:286 >> 286 =C2=A0 =C2=A0 =C2=A0 =C2=A0 z =3D xa_fun_in_lib(10); >> 1: x/i $pc >> =3D> 0x8d22 : =C2=A0 =C2=A0str =C2=A0 =C2=A0 r3, [r7, #44] =C2= =A0 ; 0x2c >> >> On Fri, Sep 16, 2011 at 8:55 AM, Yao Qi wrote: >>> On 09/16/2011 12:39 AM, Liang Cheng wrote: >>>> Sorry for not being clear. >>>> Here is the debug session getting SIGSEGV. xa_fun_in_lib is the >>>> function defined in shared library, and its symbols has been found by >>>> gdb. =C2=A0Step instruction also caused the same issue. The reason tha= t I >>>> attach those disassemble dump is to avoid rounds of ask-give. =C2=A0Le= t me >>>> know if disassemble of the piece of code is needed. =C2=A0Any idea of = why >>>> it happens? >>>> >>> >>> This debug session is much clear than last one. =C2=A0Thanks. >>> >>>> Breakpoint 1, main (argc=3D1, argv=3D0xbef25ca4) at vendor/altestavpla= yback.c:284 >>>> 284 =C2=A0 =C2=A0 =C2=A0 =C2=A0 CheckErr(res); >>>> 3: x/i $pc >>>> =3D> 0x8d12 : =C2=A0 =C2=A0ldr =C2=A0 =C2=A0 r0, [r7, #52] = =C2=A0 ; 0x34 >>>> (gdb) n >>>> 286 =C2=A0 =C2=A0 =C2=A0 =C2=A0 z =3D xa_fun_in_lib(10); >>>> 3: x/i $pc >>>> =3D> 0x8d18 : =C2=A0 =C2=A0mov.w =C2=A0 r0, #10 >>>> (gdb) s >>>> >>> >>> Before you run `step', turn on some debug output first. =C2=A0Like this= `set >>> debug infrun 1'. =C2=A0Then, when you run `step', you can see some debug >>> output, which will show how PC is changed and events inferior gets >>> during command `step'. >>> >>> However, before we go into the details of debug output, could you check >>> whether GDB cvs trunk works or not. =C2=A0You just have to build gdb fo= r arm, >>> and I think GDB cvs trunk should be able to work with your 7.2 gdbserve= r. >>> >>>> Program received signal SIGSEGV, Segmentation fault. >>>> 0x00008d22 in main (argc=3D1, argv=3D0xbef25ca4) at vendor/altestavpla= yback.c:286 >>>> 286 =C2=A0 =C2=A0 =C2=A0 =C2=A0 z =3D xa_fun_in_lib(10); >>>> 3: x/i $pc >>>> =3D> 0x8d22 : =C2=A0 =C2=A0str =C2=A0 =C2=A0 r3, [r7, #44] = =C2=A0 ; 0x2c >>>> (gdb) info address xa_fun_in_lib >>>> Symbol "xa_fun_in_lib(int)" is a function at address 0x800036fc. >>>> >>>> On Thu, Sep 15, 2011 at 11:13 AM, Yao Qi wrote: >>>>> On 09/15/2011 12:21 AM, Liang Cheng wrote: > > > -- > Yao (=E9=BD=90=E5=B0=A7) >