From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id YwnLGCEkvmD2KwAAWB0awg (envelope-from ) for ; Mon, 07 Jun 2021 09:50:25 -0400 Received: by simark.ca (Postfix, from userid 112) id 5849C1F163; Mon, 7 Jun 2021 09:50:25 -0400 (EDT) X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-1.1 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,MAILING_LIST_MULTI,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.2 Received: from sourceware.org (server2.sourceware.org [8.43.85.97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPS id B69C51E813 for ; Mon, 7 Jun 2021 09:50:22 -0400 (EDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 7F829383800F for ; Mon, 7 Jun 2021 13:50:22 +0000 (GMT) Received: from mail-wm1-x32d.google.com (mail-wm1-x32d.google.com [IPv6:2a00:1450:4864:20::32d]) by sourceware.org (Postfix) with ESMTPS id F36B23850400 for ; Mon, 7 Jun 2021 13:48:20 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org F36B23850400 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=embecosm.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=embecosm.com Received: by mail-wm1-x32d.google.com with SMTP id s70-20020a1ca9490000b02901a589651424so4003074wme.0 for ; Mon, 07 Jun 2021 06:48:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=embecosm.com; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=eykVU0TbhIJKiSMHCCXOxxjZUXneEJBgBxgEmCSOfqs=; b=E7Ze6FoVZOGyri2POYDpImIgaMjJT3qA5km4bcDp7ZKxItqO4bx7xY6xgTlc2Sbm2B osDG4vTtMg56Nqae+nRFME7KXnyyYzBaQK7iHs78NtqBAqlYFQU/OTi2bjiS7Yygpty8 G4YRjHFSr3z7a8QwlEYRJKI1YYisovphx20ANASmGZXfb0V8SJCAtvYRM1MBlmEuAmlG hDs0BG7UBC/4ZyoabuYYLg/j7L+6dqP8dqLmpRBDXhMSfClK3I93v6/lX746UpjfXKSP bIcltc7mOm7EHh0KSXvUbTpfdLGqgY3InwQOzLpTAdjF3Ma0qh6Q4QmQ5LuAvHIK8iiY WEHw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=eykVU0TbhIJKiSMHCCXOxxjZUXneEJBgBxgEmCSOfqs=; b=Kj84s8IrpJoybrsKw0jhhbzazhR6eQzFZW23RMHYajxy3s2qiJHLoguzLyCQyYXxPQ hQ5gndZx8jUypCfavtzb6q4f6jsXGheqZFa0bLrvNygk+Gl8BnG/CVHEqx1bBONCRinV p6gxrAx/z8fo0f39kleJ0hkFzH5RrKx6tUgEIcFKKfXHdjy3X0RWQepZgWVSKQwo2wKH G/QvmqnVZNRNIgoOjgc4dgSBoQG7IneZGyE4oTZ2Nbfexi/Su0jPjavy7X5b/jjkBNHS 9UQrySUUvf9CiYAKHOp6Susb2Pil7N1DGQg1uKeEaxoJmd208oZ/C0BYxZYdPCM+aOK8 DiAQ== X-Gm-Message-State: AOAM5328QpAcI/qVN9qQTpsim/Ep1uCmmwF84MXhxbV6JRv9FCFnj38y +8AC1LzOcyZcbb1tfpwFv/My2g== X-Google-Smtp-Source: ABdhPJxN36QUjruOQUs6g1K5C5NJ/qNQzLfP6WIh6RRYk52wUWjlWi1IKtRjLEH+/M2+fuRRw+hs7Q== X-Received: by 2002:a05:600c:4fd6:: with SMTP id o22mr17085971wmq.83.1623073700099; Mon, 07 Jun 2021 06:48:20 -0700 (PDT) Received: from localhost (host109-151-46-70.range109-151.btcentralplus.com. [109.151.46.70]) by smtp.gmail.com with ESMTPSA id a11sm16089020wrr.48.2021.06.07.06.48.19 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 07 Jun 2021 06:48:19 -0700 (PDT) Date: Mon, 7 Jun 2021 14:48:18 +0100 From: Andrew Burgess To: "aleksandar.paunovic" Subject: Re: [PATCH 2/2] gdb: Improve the resuming of the stepped thread Message-ID: <20210607134818.GT2672@embecosm.com> References: <1623055323-3331-1-git-send-email-aleksandar.paunovic@intel.com> <1623055323-3331-3-git-send-email-aleksandar.paunovic@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1623055323-3331-3-git-send-email-aleksandar.paunovic@intel.com> X-Operating-System: Linux/5.8.18-100.fc31.x86_64 (x86_64) X-Uptime: 14:42:35 up 19 days, 3:26, X-Editor: GNU Emacs [ http://www.gnu.org/software/emacs ] X-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: gdb-patches@sourceware.org Errors-To: gdb-patches-bounces+public-inbox=simark.ca@sourceware.org Sender: "Gdb-patches" * aleksandar.paunovic via Gdb-patches [2021-06-07 10:42:03 +0200]: > From: Aleksandar Paunovic > > Stepped thread should not be resumed (again) if the next stopping point > (next stopping PC) cannot be determined. Do not resume the stepped thread > in this case. Resuming would lead to an inconsistent state where the > stepped thread would be running forever and GDB would never get to > breakpoints of the other threads. */ > > gdb/ChangeLog: > 2021-04-30 Aleksandar Paunovic > > * infrun.c (keep_going_stepped_thread): Do not resume an > already executing thread. > > gdb/testsuite/ChangeLog: > 2021-04-30 Aleksandar Paunovic > > * gdb.base/breakpoint-running-inferior.exp: Add a start_step > function check. > > 2021-06-07 Aleksandar Paunovic > --- > gdb/infrun.c | 15 ++++++++++++++- > .../gdb.base/breakpoint-running-inferior.exp | 5 +++++ > 2 files changed, 19 insertions(+), 1 deletion(-) > > diff --git a/gdb/infrun.c b/gdb/infrun.c > index 78da1f0e72..459a679ee6 100644 > --- a/gdb/infrun.c > +++ b/gdb/infrun.c > @@ -7529,7 +7529,7 @@ restart_after_all_stop_detach (process_stratum_target *proc_target) > > /* Set a previously stepped thread back to stepping. Returns true on > success, false if the resume is not possible (e.g., the thread > - vanished). */ > + vanished, or the thread breakpoint position cannot be determined). */ > > static bool > keep_going_stepped_thread (struct thread_info *tp) > @@ -7566,6 +7566,19 @@ keep_going_stepped_thread (struct thread_info *tp) > delete_thread (tp); > return false; > } > + /* Step start function determines the location of the next stopping > + point (next PC where the stepped thread should stop). In case that > + this position cannot be determined the step_start_function will not > + be set. Do not resume the stepped thread in this case. Resuming > + would lead to an inconsistent state where the stepped thread would be > + running forever and GDB would never get to breakpoints of the other > + threads. */ > + if (tp->control.step_start_function == nullptr) > + { > + infrun_debug_printf ("not resuming previously stepped thread, it is " > + "already executing"); > + return 0; I don't understand why the condition you're checking means that the thread is already executing. Also, your comment says step_start_function is the pc where we should next stop, but it is set with find_pc_function, which just gives the symbol for the function containing the $pc when the step/next was started, so I don't understand why this tells GDB where to stop. Also 'return false'. Thanks, Andrew > + } > > infrun_debug_printf ("resuming previously stepped thread"); > > diff --git a/gdb/testsuite/gdb.base/breakpoint-running-inferior.exp b/gdb/testsuite/gdb.base/breakpoint-running-inferior.exp > index bb0406bc65..b95f2ec012 100644 > --- a/gdb/testsuite/gdb.base/breakpoint-running-inferior.exp > +++ b/gdb/testsuite/gdb.base/breakpoint-running-inferior.exp > @@ -74,10 +74,15 @@ gdb_test "next" ".*Thread 2.*hit Breakpoint.*" "next while in inferior 1" > > # We should be able to normally switch to thread 1.1. > # In case of a bad GDB flow the GDB was losing the thread. > +# The thread should also not be in a "running" state because it is > +# stopped. > gdb_test_multiple "thread 1.1" "Switching to thread 1.1" { > -re "\\\[Switching to thread 1.1 \\(Thread .*\\)\\\]" { > pass $gdb_test_name > } > + -re "\\\[Switching to thread 1.1.*\\(running\\)" { > + fail $gdb_test_name > + } > -re ".*Thread ID 1.1 has terminated.*" { > fail $gdb_test_name > } > -- > 2.17.1 >