From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22739 invoked by alias); 19 Sep 2011 22:18:00 -0000 Received: (qmail 22724 invoked by uid 22791); 19 Sep 2011 22:17:57 -0000 X-SWARE-Spam-Status: No, hits=-1.1 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_XT X-Spam-Check-By: sourceware.org Received: from mail-ey0-f169.google.com (HELO mail-ey0-f169.google.com) (209.85.215.169) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 19 Sep 2011 22:17:39 +0000 Received: by eye13 with SMTP id 13so2455382eye.0 for ; Mon, 19 Sep 2011 15:17:37 -0700 (PDT) MIME-Version: 1.0 Received: by 10.213.3.155 with SMTP id 27mr23629ebn.50.1316470657262; Mon, 19 Sep 2011 15:17:37 -0700 (PDT) Received: by 10.213.105.144 with HTTP; Mon, 19 Sep 2011 15:17:37 -0700 (PDT) In-Reply-To: References: <4E72241F.5060402@codesourcery.com> <4E735536.1000405@codesourcery.com> <4E73F7B7.9070800@codesourcery.com> Date: Mon, 19 Sep 2011 22:18: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/msg00066.txt.bz2 But it seems to close what I want. But the extension gets the PC wrong, it should be 0x800036fd. Why we use nextpc =3D (CORE_ADDR)read_memory_integer ((CORE_ADDR) ba= se, 4, byte_order); instead of nextpc =3D (CORE_ADDR)read_memory_unsigned integer ((CORE_ADDR) base, 4, byte_order); in arm-tdep.c::arm_get_next_pc_raw? Below is the stack in debug session of = gdb. thanks (gdb) c Continuing. Breakpoint 1, arm_get_next_pc (frame=3D0x40d9720, pc=3D34352) at arm-tdep.c= :4854 4854 { (gdb) bt #0 arm_get_next_pc (frame=3D0x40d9720, pc=3D34352) at arm-tdep.c:4854 #1 0x0000000000431b0c in arm_linux_software_single_step (frame=3D0x40d9720) at arm-linux-tdep.c:751 #2 0x00000000004d8321 in maybe_software_singlestep (gdbarch=3D0x13cc920, pc=3D34352) at infrun.c:1577 #3 0x00000000004dabad in resume (step=3D1, sig=3DTARGET_SIGNAL_0) at infru= n.c:1689 #4 0x00000000004dfbf0 in proceed (addr=3D, siggnal=3DTARGET_SIGNAL_DEFAULT, step=3D1) at infrun.c:2128 #5 0x00000000004d2227 in step_once (skip_subroutines=3D0, single_inst=3D1, count=3D1, thread=3D-1) at infcmd.c:1046 #6 0x00000000004d40d4 in step_1 (skip_subroutines=3D0, single_inst=3D1, count_string=3D0x0) at infcmd.c:894 (gdb) n 4857 if (arm_frame_is_thumb (frame)) (gdb) n 4866 if (nextpc =3D=3D pc) (gdb) p pc $1 =3D 34352 (gdb) p /x pc $2 =3D 0x8630 (gdb) p /x nextpc $3 =3D 0xffffffff800036fd On Mon, Sep 19, 2011 at 10:57 AM, Liang Cheng wr= ote: > 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 =C2=A0 =C2=A0 =C2=A0 =C2=A0 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: =C2=A0 1874 [Thread 1874.1874], > 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 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: =C2=A0 1874 [Thread 1874.1874], > 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 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: =C2=A0 1874 [Thread 1874.1874], > 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 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: =C2=A0 1874 [Thread 1874.1874], > 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 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: =C2=A0 1874 [Thread 1874.1874], > infrun: =C2=A0 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: =C2=A0 1874 [Thread 1874.1874], > infrun: =C2=A0 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: =C2=A0 1874 [Thread 1874.1874], > infrun: =C2=A0 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 =C2=A0 =C2=A0 =C2=A0 =C2=A0 res =3D (*engine)->Realize(engine, XA_BOO= LEAN_FALSE); > (gdb) display /i $pc > 1: x/i $pc > =3D> 0x8d24 : =C2=A0 =C2=A0ldr =C2=A0 =C2=A0 r3, [r7, #48] =C2= =A0 ; 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 = error. >>> 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, rath= er >> 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/altestavplay= back.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 brea= kpoints >> =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, = using >> 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/altestavplay= back.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 th= at I >>>>> attach those disassemble dump is to avoid rounds of ask-give. =C2=A0L= et 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/altestavpl= ayback.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 thi= s `set >>>> debug infrun 1'. =C2=A0Then, when you run `step', you can see some deb= ug >>>> 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 f= or arm, >>>> and I think GDB cvs trunk should be able to work with your 7.2 gdbserv= er. >>>> >>>>> Program received signal SIGSEGV, Segmentation fault. >>>>> 0x00008d22 in main (argc=3D1, argv=3D0xbef25ca4) at vendor/altestavpl= ayback.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) >> >