From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 56147 invoked by alias); 15 Jun 2015 12:12:35 -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 56133 invoked by uid 89); 15 Jun 2015 12:12:35 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-0.2 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-ob0-f180.google.com Received: from mail-ob0-f180.google.com (HELO mail-ob0-f180.google.com) (209.85.214.180) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-GCM-SHA256 encrypted) ESMTPS; Mon, 15 Jun 2015 12:12:33 +0000 Received: by obbgp2 with SMTP id gp2so62331718obb.2 for ; Mon, 15 Jun 2015 05:12:31 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.182.79.197 with SMTP id l5mr2505739obx.70.1434370351355; Mon, 15 Jun 2015 05:12:31 -0700 (PDT) Received: by 10.202.184.213 with HTTP; Mon, 15 Jun 2015 05:12:31 -0700 (PDT) In-Reply-To: <7AB3878D-0DDE-4C0A-912E-AD0867938349@gmail.com> References: <7AB3878D-0DDE-4C0A-912E-AD0867938349@gmail.com> Date: Mon, 15 Jun 2015 12:12:00 -0000 Message-ID: Subject: Re: Is there single step debugging support being added to aarch64-linux? From: Prafull Suryawanshi To: pinskia@gmail.com Cc: Andreas Schwab , "gdb@sourceware.org" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes X-SW-Source: 2015-06/txt/msg00022.txt.bz2 Thanks. Adding one. Will send it to gdb-patches. -Prafull On Mon, Jun 15, 2015 at 5:27 PM, wrote: > > > > >> On Jun 15, 2015, at 4:48 AM, Prafull Suryawanshi = wrote: >> >> 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. > > Thanks, > Andrew > >> >> Thanks, >> Prafull >> >>> On Mon, Jun 15, 2015 at 4:49 PM, wrote: >>> >>> >>> >>> >>>> On Jun 15, 2015, at 4:07 AM, Prafull Suryawanshi wrote: >>>> >>>> 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. >>>> >>>> In fact, I had small implementation to get next_pc at fixed offset >>>> (+4) and it starts working. (implementing full version) >>> >>> >>> Why can't you use the hardware single stepper for kgdb? >>> >>> Thanks, >>> Andrew >>> >>>> >>>> Let me know. >>>> >>>> Thanks, >>>> Prafull >>>> >>>> >>>> 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) >>>>> >>>>> infrun: clear_proceed_status_thread (Thread 3462) >>>>> infrun: clear_proceed_status_thread (Thread 3444) >>>>> infrun: proceed (addr=3D0xffffffffffffffff, signal=3DGDB_SIGNAL_DEFAU= LT, step=3D1) >>>>> infrun: resume (step=3D1, signal=3DGDB_SIGNAL_0), trap_expected=3D1, = current >>>>> 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: >>>>> c045b049c0ffffff01000000000000004c012100c0fffffff912a660c0ffffff28849= f36c0ffffff000000000000000030334901c0ffffff00000000000000003f00000000000000= 0000000000000000009000000000000001000000000000000100000000000000c0128008200= 00000c012800820000000c0e0000000000000d8981a00c0ffffffdc1c650820000000c01280= 0820000000c045b049c0ffffff010000000000000001000000000000000000000000000000c= 8be0d35c0ffffff80e91b58c0ffffff0010000000000000f845b049c0ffffff00a0c5082000= 000000800d35c0ffffffc0bd0d35c0fffffffcea1c00c0fffffff0bb0d35c0ffffff5001210= 0c0ffffff450100000000000000000000000000000000000000000000000000000000000000= 000000000000000000000000000000000000000000000000000000000000000000000000000= 000000000000000000000000000000000000000000000000000000000000000000000000000= 000000000000000000000000000000000000000000000000000000000000000000000000000= 000000000000000000000000000000000000000000000000000000000000000000000000000= 000000000000000000000000000000000000000000000000000000000000000000000000000= 000000000000000000000000000000000000000000000000000000000000000000000000000= 000000000000000000000000000000000000000000000000000000000000000000000000000= 000000000000000000000000000000000000000000000000000000000000000000000000000= 000000000000000000000000000000000000000000000000000000000000000000000000000= 000000000000000000000000000000000000000000000000000000000000000000000000000= 000000000000000000000000000000000000000000000000000000000000000000000000000= 000000000000000000000000000000000000000000000000000000000000000000000000000= 000000000000000000000000000000000000000000000000000000000000000000000000000= 000000000000000 >>>>> 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, = current >>>>> thread [Thread 3462] at 0xffffffc000210150 >>>>> Sending packet: $Hc0#db...Ack >>>>> Packet received: OK >>>>> Sending packet: $s#73...Ack >>>>> infrun: prepare_to_wait >>>>> >>>>> Then I build the gdb using arch_dump enable option >>>>> gdbarch_dump: gdbarch_software_single_step_p() =3D 0 >>>>> >>>>> I see that in gdb code, function aarch64_linux_software_single_step n= ot present. >>>>> >>>>> I guess above loop expected if aarch64_linux_software_single_step abs= ent, right? >>>>> >>>>> Thanks, >>>>> Prafull >>>>> >>>>>> On Mon, Jun 15, 2015 at 4:08 PM, Andreas Schwab wro= te: >>>>>> Prafull Suryawanshi writes: >>>>>> >>>>>>> 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? >>>>>> >>>>>> The stepi command is working fine on aarch64. What do you get if you >>>>>> try it? >>>>>> >>>>>> Andreas. >>>>>> >>>>>> -- >>>>>> Andreas Schwab, SUSE Labs, schwab@suse.de >>>>>> GPG Key fingerprint =3D 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EE= A B9D7 >>>>>> "And now for something completely different."