From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14130 invoked by alias); 15 Jun 2015 11:57:14 -0000 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 Received: (qmail 14116 invoked by uid 89); 15 Jun 2015 11:57:13 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,KAM_LOTSOFHASH,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mail-pa0-f54.google.com Received: from mail-pa0-f54.google.com (HELO mail-pa0-f54.google.com) (209.85.220.54) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-GCM-SHA256 encrypted) ESMTPS; Mon, 15 Jun 2015 11:57:11 +0000 Received: by pacyx8 with SMTP id yx8so64422837pac.2 for ; Mon, 15 Jun 2015 04:57:09 -0700 (PDT) X-Received: by 10.70.108.137 with SMTP id hk9mr47564933pdb.105.1434369429585; Mon, 15 Jun 2015 04:57:09 -0700 (PDT) Received: from [192.168.1.35] (76-253-1-90.lightspeed.sntcca.sbcglobal.net. [76.253.1.90]) by mx.google.com with ESMTPSA id ss3sm12110445pab.43.2015.06.15.04.57.07 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 15 Jun 2015 04:57:08 -0700 (PDT) References: Mime-Version: 1.0 (1.0) In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <7AB3878D-0DDE-4C0A-912E-AD0867938349@gmail.com> Cc: Andreas Schwab , "gdb@sourceware.org" From: pinskia@gmail.com Subject: Re: Is there single step debugging support being added to aarch64-linux? Date: Mon, 15 Jun 2015 11:57:00 -0000 To: Prafull Suryawanshi X-IsSubscribed: yes X-SW-Source: 2015-06/txt/msg00021.txt.bz2 > On Jun 15, 2015, at 4:48 AM, Prafull Suryawanshi = wrote: >=20 > I am not sure why hw stepper not works here (might be limitation of hw > I am using). > That is may be the infrun loops as it never gets stop signal. (the > output I earlier pasted). > Is it ok to provide patch for software single step like arm here? > (I am preparing one. It will have simulate aarch64 instruction set and > implement aarch64 version of functions of > arm_linux_software_single_step, arm_insert_single_step_breakpoint and > arm_get_next_pc.) We do need one but for stepping over ldxr/stxr pairs.=20 Thanks, Andrew >=20 > Thanks, > Prafull >=20 >> On Mon, Jun 15, 2015 at 4:49 PM, wrote: >>=20 >>=20 >>=20 >>=20 >>> On Jun 15, 2015, at 4:07 AM, Prafull Suryawanshi wrote: >>>=20 >>> I am using gdb to talk to kgdb, so is not issue with gdb? >>> gdb is not able to set software single step like it do for arm. >>> There is implementation for gdbarch_software_single_step_p in arm gdb >>> but not in aarch64 gdb. >>>=20 >>> In fact, I had small implementation to get next_pc at fixed offset >>> (+4) and it starts working. (implementing full version) >>=20 >>=20 >> Why can't you use the hardware single stepper for kgdb? >>=20 >> Thanks, >> Andrew >>=20 >>>=20 >>> Let me know. >>>=20 >>> Thanks, >>> Prafull >>>=20 >>>=20 >>> On Mon, Jun 15, 2015 at 4:27 PM, Prafull Suryawanshi >>> wrote: >>>> I am using kgdb and trying to do single step (software single step). >>>> I see that infrun loops. (I enabled remote_debug option and compiled >>>> gdb 7.7 as 7.9 has issue with connection) >>>>=20 >>>> infrun: clear_proceed_status_thread (Thread 3462) >>>> infrun: clear_proceed_status_thread (Thread 3444) >>>> infrun: proceed (addr=3D0xffffffffffffffff, signal=3DGDB_SIGNAL_DEFAUL= T, step=3D1) >>>> infrun: resume (step=3D1, signal=3DGDB_SIGNAL_0), trap_expected=3D1, c= urrent >>>> thread [Thread 3462] at 0xffffffc00021014c >>>> Sending packet: $Hcd86#7d...Ack >>>> Packet received: OK >>>> Sending packet: $s#73...Ack >>>> infrun: wait_for_inferior () >>>> Packet received: T05thread:0d86; >>>> infrun: target_wait (-1, status) =3D >>>> infrun: 42000 [Thread 3462], >>>> infrun: status->kind =3D stopped, signal =3D GDB_SIGNAL_TRAP >>>> infrun: infwait_normal_state >>>> infrun: TARGET_WAITKIND_STOPPED >>>> Sending packet: $g#67...Ack >>>> Packet received: >>>> c045b049c0ffffff01000000000000004c012100c0fffffff912a660c0ffffff28849f= 36c0ffffff000000000000000030334901c0ffffff00000000000000003f000000000000000= 000000000000000009000000000000001000000000000000100000000000000c01280082000= 0000c012800820000000c0e0000000000000d8981a00c0ffffffdc1c650820000000c012800= 820000000c045b049c0ffffff010000000000000001000000000000000000000000000000c8= be0d35c0ffffff80e91b58c0ffffff0010000000000000f845b049c0ffffff00a0c50820000= 00000800d35c0ffffffc0bd0d35c0fffffffcea1c00c0fffffff0bb0d35c0ffffff50012100= c0ffffff4501000000000000000000000000000000000000000000000000000000000000000= 000000000000000000000000000000000000000000000000000000000000000000000000000= 000000000000000000000000000000000000000000000000000000000000000000000000000= 000000000000000000000000000000000000000000000000000000000000000000000000000= 000000000000000000000000000000000000000000000000000000000000000000000000000= 000000000000000000000000000000000000000000000000000000000000000000000000000= 000000000000000000000000000000000000000000000000000000000000000000000000000= 000000000000000000000000000000000000000000000000000000000000000000000000000= 000000000000000000000000000000000000000000000000000000000000000000000000000= 000000000000000000000000000000000000000000000000000000000000000000000000000= 000000000000000000000000000000000000000000000000000000000000000000000000000= 000000000000000000000000000000000000000000000000000000000000000000000000000= 000000000000000000000000000000000000000000000000000000000000000000000000000= 000000000000000000000000000000000000000000000000000000000000000000000000000= 00000000000000 >>>> infrun: stop_pc =3D 0xffffffc000210150 >>>> Sending packet: $mffffffc000210150,4#4d...Ack >>>> Packet received: fd030091 >>>> Sending packet: $mffffffc00021014c,4#7f...Ack >>>> Packet received: fd7ba3a9 >>>> Sending packet: $mffffffc000210150,4#4d...Ack >>>> Packet received: fd030091 >>>> infrun: stepping inside range [0xffffffc00021014c-0xffffffc000210170] >>>> Sending packet: $Z0,ffffffc00021014c,4#c8...Ack >>>> Packet received: OK >>>> infrun: resume (step=3D1, signal=3DGDB_SIGNAL_0), trap_expected=3D0, c= urrent >>>> thread [Thread 3462] at 0xffffffc000210150 >>>> Sending packet: $Hc0#db...Ack >>>> Packet received: OK >>>> Sending packet: $s#73...Ack >>>> infrun: prepare_to_wait >>>>=20 >>>> Then I build the gdb using arch_dump enable option >>>> gdbarch_dump: gdbarch_software_single_step_p() =3D 0 >>>>=20 >>>> I see that in gdb code, function aarch64_linux_software_single_step no= t present. >>>>=20 >>>> I guess above loop expected if aarch64_linux_software_single_step abse= nt, right? >>>>=20 >>>> Thanks, >>>> Prafull >>>>=20 >>>>> On Mon, Jun 15, 2015 at 4:08 PM, Andreas Schwab wrot= e: >>>>> Prafull Suryawanshi writes: >>>>>=20 >>>>>> I am trying it on 64 bit armv8 system but not able to doit. >>>>>> Found issue in gdb source code and absence of this function in >>>>>> aarch64-linux-tdep.c file. Anyone knows if support getting added or >>>>>> not? >>>>>=20 >>>>> The stepi command is working fine on aarch64. What do you get if you >>>>> try it? >>>>>=20 >>>>> Andreas. >>>>>=20 >>>>> -- >>>>> Andreas Schwab, SUSE Labs, schwab@suse.de >>>>> GPG Key fingerprint =3D 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA= B9D7 >>>>> "And now for something completely different."