From patchwork Thu Sep 1 16:44:25 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Yao Qi X-Patchwork-Id: 15166 Received: (qmail 71661 invoked by alias); 1 Sep 2016 16:44:38 -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 70754 invoked by uid 89); 1 Sep 2016 16:44:38 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.7 required=5.0 tests=AWL, BAYES_00, FREEMAIL_FROM, RCVD_IN_DNSWL_LOW, RCVD_IN_SORBS_SPAM, SPF_PASS autolearn=no version=3.3.2 spammy=beside, momentarily, proceeding X-HELO: mail-oi0-f53.google.com Received: from mail-oi0-f53.google.com (HELO mail-oi0-f53.google.com) (209.85.218.53) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 01 Sep 2016 16:44:28 +0000 Received: by mail-oi0-f53.google.com with SMTP id r205so45107979oih.3 for ; Thu, 01 Sep 2016 09:44:27 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=RzAYtQX5W7mWB4+XGXL4NcW6jz6GLfnSCznC2wGcCvc=; b=Luj46axSmubUhs50Y6eH3nIl82yC5Occm2hJsGH83IdxUz5hzS5Ds1YdRqGO6IBecF 1R1I294IrOaakZ3OlBGRLVwX/T/O98MesaanPQKOKaqTHhNa2iX0Lc/1DitvGXlQ/tyr iQlhwB+FzPPZ88xQTnLiPWmCaPB6ENtDHVTXZshS8NStnlhU/+vWgNUQXgO8froyCSEW ZzUxf8Xvdo77sFRndr4kxj/pf7/YxS60dfSS8iJ0opwzob4JDyhQ+/T1vs5jrdZobgYY woDhUeCFPS3qH94NgCucwLaMFwsk2m8wjDe6+d9cm14ByNiYJaOCfBeJcFNWEU35ZpfG uCiA== X-Gm-Message-State: AE9vXwNNdlaZq5HctzeotWe52MgchYt61sqXsvlpyRHJ7hhJ1+6TGazxA7eXuRBnOewGr86Mz7ZT5cIB1UrjFw== X-Received: by 10.157.35.4 with SMTP id j4mr17221796otb.38.1472748266480; Thu, 01 Sep 2016 09:44:26 -0700 (PDT) MIME-Version: 1.0 Received: by 10.202.79.201 with HTTP; Thu, 1 Sep 2016 09:44:25 -0700 (PDT) In-Reply-To: References: <20160831171406.24057-1-antoine.tremblay@ericsson.com> <20160831171406.24057-2-antoine.tremblay@ericsson.com> <3fdb7193-60c7-49c9-ccf5-bc040aa157ea@redhat.com> From: Yao Qi Date: Thu, 1 Sep 2016 17:44:25 +0100 Message-ID: Subject: Re: [PATCH 2/2] Enable range stepping for ARM on GDBServer To: Pedro Alves Cc: Antoine Tremblay , "gdb-patches@sourceware.org" X-IsSubscribed: yes [sigh, I am testing my arm range stepping patches today...] On Thu, Sep 1, 2016 at 4:59 PM, Pedro Alves wrote: >>> >>>> I'm sorry I can't be more helpful at the moment but I wanted to post >>>> this issue before I have to leave for a while. >>> >>> Understood. Does enabling range stepping unblock something else? >> >> It would unblock ARM tracepoints, as per Yao's requirements... > > Tracepoints make gdbserver single-step and then not report the event > to gdb, so I do see the parallel with range-stepping. Throwing > while-stepping into the equation would make it even more clear. > Range-stepping makes gdbserver single-step and then not report the event to gdb if thread pc is within the range. It is similar to tracepoint, but much simpler. Both range-stepping and tracepoing needs to remove reinsert_breakpoint when gdbserver gets an event but doesn't report it back to gdb. However, gdbserver doesn't do so now. That is the reason I believe we need to support range-stepping first, and I am working on this (but interrupted by 7.12 release). The draft patch attached removes reinsert_breakpoint when gdbserver gets an event but not to report it back to gdb. Beside "removing reinsert_breakpoint on gdbserver internal event", we'd better to think that "each backend unwinders don't have to worry about unavailable data". I posted a draft here https://sourceware.org/ml/gdb-patches/2016-05/msg00060.html, I need some review comments. Pedro, can you take a look? This is not a hard requirement for ARM tracepoint support. diff --git a/gdb/gdbserver/linux-low.c b/gdb/gdbserver/linux-low.c index 45061ac..2f30bc1 100644 --- a/gdb/gdbserver/linux-low.c +++ b/gdb/gdbserver/linux-low.c @@ -3662,17 +3662,31 @@ linux_wait_1 (ptid_t ptid, (*the_low_target.set_pc) (regcache, event_child->stop_pc); } - /* We may have finished stepping over a breakpoint. If so, - we've stopped and suspended all LWPs momentarily except the - stepping one. This is where we resume them all again. We're - going to keep waiting, so use proceed, which handles stepping - over the next breakpoint. */ - if (debug_threads) - debug_printf ("proceeding all threads.\n"); - if (step_over_finished) - unsuspend_all_lwps (event_child); + { + /* If we have finished stepping over a breakpoint, we've + stopped and suspended all LWPs momentarily except the + stepping one. This is where we resume them all again. + We're going to keep waiting, so use proceed, which + handles stepping over the next breakpoint. */ + unsuspend_all_lwps (event_child); + } + else + { + /* Remove the singlestep breakpoints if any. Note that + there isn't singlestep breakpoint if we finished stepping + over. */ + if (can_software_single_step () + && has_reinsert_breakpoints (current_thread)) + { + stop_all_lwps (0, event_child); + delete_reinsert_breakpoints (current_thread); + unstop_all_lwps (0, event_child); + } + } + if (debug_threads) + debug_printf ("proceeding all threads.\n"); proceed_all_lwps (); return ignore_event (ourstatus); }