From patchwork Tue Mar 17 14:52:02 2015 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Yao Qi X-Patchwork-Id: 5652 Received: (qmail 56683 invoked by alias); 17 Mar 2015 14:52:08 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Delivered-To: mailing list gdb-patches@sourceware.org Received: (qmail 56644 invoked by uid 89); 17 Mar 2015 14:52:08 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=2.3 required=5.0 tests=AWL, BAYES_00, FREEMAIL_FROM, KAM_FROM_URIBL_PCCC, RCVD_IN_DNSWL_LOW, SPF_PASS autolearn=no version=3.3.2 X-HELO: mail-pa0-f42.google.com Received: from mail-pa0-f42.google.com (HELO mail-pa0-f42.google.com) (209.85.220.42) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-GCM-SHA256 encrypted) ESMTPS; Tue, 17 Mar 2015 14:52:07 +0000 Received: by pagr17 with SMTP id r17so12008935pag.0 for ; Tue, 17 Mar 2015 07:52:05 -0700 (PDT) X-Received: by 10.66.66.196 with SMTP id h4mr149144485pat.127.1426603925784; Tue, 17 Mar 2015 07:52:05 -0700 (PDT) Received: from E107787-LIN.cambridge.arm.com (gcc1-power7.osuosl.org. [140.211.15.137]) by mx.google.com with ESMTPSA id tg14sm22912515pac.15.2015.03.17.07.52.04 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 17 Mar 2015 07:52:04 -0700 (PDT) From: Yao Qi To: gdb-patches@sourceware.org Subject: [rfc, spu] Don't call set_gdbarch_cannot_step_breakpoint in spu_gdbarch_init Date: Tue, 17 Mar 2015 14:52:02 +0000 Message-Id: <1426603922-24107-1-git-send-email-qiyaoltc@gmail.com> X-IsSubscribed: yes From: Yao Qi Nowadays, in infrun.c:resume, the setting to 'step' variable is like: if (use_displaced_stepping (gdbarch) && tp->control.trap_expected && sig == GDB_SIGNAL_0 && !current_inferior ()->waiting_for_vfork_done) { } /* Do we need to do it the hard way, w/temp breakpoints? */ else if (step) step = maybe_software_singlestep (gdbarch, pc); <-- [1] ... if (execution_direction != EXEC_REVERSE && step && breakpoint_inserted_here_p (aspace, pc)) { ... if (gdbarch_cannot_step_breakpoint (gdbarch)) <-- [2] step = 0; } spu doesn't have displaced stepping and uses software single step, so 'step' is set to zero in [1], and [2] becomes unreachable as a result. So don't have to call set_gdbarch_cannot_step_breakpoint in spu_gdbarch_init. On the other hand, we either have hardware single step or software single step, do we still need gdbarch method cannot_step_breakpoint? CANNOT_STEP_BREAKPOINT was introduced in 1993 by commit cef4c2e7a5f2d3426a8255f74b6c7f4e795fd9a4 for alpha OSF/1 native support. I don't have spu machine to test this patch. gdb: 2015-03-17 Yao Qi * spu-tdep.c (spu_gdbarch_init): Don't call set_gdbarch_cannot_step_breakpoint. --- gdb/spu-tdep.c | 1 - 1 file changed, 1 deletion(-) diff --git a/gdb/spu-tdep.c b/gdb/spu-tdep.c index 36ad312..870cf32 100644 --- a/gdb/spu-tdep.c +++ b/gdb/spu-tdep.c @@ -2794,7 +2794,6 @@ spu_gdbarch_init (struct gdbarch_info info, struct gdbarch_list *arches) set_gdbarch_decr_pc_after_break (gdbarch, 4); set_gdbarch_breakpoint_from_pc (gdbarch, spu_breakpoint_from_pc); set_gdbarch_memory_remove_breakpoint (gdbarch, spu_memory_remove_breakpoint); - set_gdbarch_cannot_step_breakpoint (gdbarch, 1); set_gdbarch_software_single_step (gdbarch, spu_software_single_step); set_gdbarch_get_longjmp_target (gdbarch, spu_get_longjmp_target);