From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm1-x335.google.com (mail-wm1-x335.google.com [IPv6:2a00:1450:4864:20::335]) by sourceware.org (Postfix) with ESMTPS id 69FBC3857C63 for ; Tue, 2 Mar 2021 11:26:09 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 69FBC3857C63 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=embecosm.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=andrew.burgess@embecosm.com Received: by mail-wm1-x335.google.com with SMTP id k66so2336294wmf.1 for ; Tue, 02 Mar 2021 03:26:09 -0800 (PST) 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=dgqPD7GoXy1IMG97xqLxFIXJgqROTkMPwlUjda1jVjE=; b=TloYJeuyItLTxxo+gsASEHCJ9CZ+AOYHfZrFu9//Stiy/E4cibsDqLYUeyPNpMxQlX 2RBQhD7WhfkMbjguulOYJ5qW9RY7YCKkXwEvLqS41bCp7dr4Bk/2P9HCq2/NGOSUC5Bj EjKmNSTelpCVyNtcS8hM2YetPpBvSw2pZOonj7MWGs+/J0Lp+6qutv59bfW2UeGCqLZb YiRIALuLp6GRxTz1kbi06+jq3I16VnSTTkV8yuvEdiJk3DeQkmJcxaGLT83pS8cL9C5C Gl2juvCZ/ysfI75lC/KperoLHH8Fh3UJIOB8OhJpfnBarmDHdmjQW8f8N+Np7wcm0WAn JwnA== 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=dgqPD7GoXy1IMG97xqLxFIXJgqROTkMPwlUjda1jVjE=; b=HVciZVLy+SpMliA2hYOx8nIOCRSIJkt3LZhE/rBQPI2MEXBhI/hdto6u2ZnvUSRERu 7oCnpHQdFu9ZNhYn9CWR406My28mjf7l15W9Iy9QAlhJKhoAKm2XALU3rzasZoaUx4Re 8bcF2DWneTCgLHzWeGgZvWlBqCfKnT6cfRb1XoquuK7K1Cdh9ToyVsJzPU8U5ymzQHFN aToamg0S3Ar8Zj2y6wYRRm4Ax3cM5WaM2zwI0z2dcqMCUaEAeYE1tSm0sOfgWT4/6+6i 2cSnyUSSpkOJTGn68UaoKFCL5AitzvLoH2PxtkqDuNMHhxrR6w44kHsjHlHzRSMnwWjU StOg== X-Gm-Message-State: AOAM532O30FDw6aa4gT2FITeNwplw+waKZ0QOlGr0i1mogJ2p0CUIHTN h/RIjbJxeiBmt0ChUyR7t4ZQ6w== X-Google-Smtp-Source: ABdhPJyxNzqkpgjqcJLb1ceZMzMhUrd8SU3g5EnuRe9AwLBkXNnVzQFccOVBFzeSxwxEHSq3a96IMg== X-Received: by 2002:a05:600c:3588:: with SMTP id p8mr3539731wmq.71.1614684368540; Tue, 02 Mar 2021 03:26:08 -0800 (PST) Received: from localhost (host86-186-80-154.range86-186.btcentralplus.com. [86.186.80.154]) by smtp.gmail.com with ESMTPSA id j136sm2415910wmj.35.2021.03.02.03.26.07 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 02 Mar 2021 03:26:07 -0800 (PST) Date: Tue, 2 Mar 2021 11:26:06 +0000 From: Andrew Burgess To: Natalia Saiapova Cc: gdb-patches@sourceware.org Subject: Re: [PATCH v2 3/6] gdb/infcall: in condition evaluation register target back after infcall. Message-ID: <20210302112606.GQ265215@embecosm.com> References: <20201009112719.629-1-natalia.saiapova@intel.com> <20201009112719.629-4-natalia.saiapova@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20201009112719.629-4-natalia.saiapova@intel.com> X-Operating-System: Linux/5.8.13-100.fc31.x86_64 (x86_64) X-Uptime: 11:22:56 up 83 days, 16:07, X-Editor: GNU Emacs [ http://www.gnu.org/software/emacs ] X-Spam-Status: No, score=-12.0 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, GIT_PATCH_0, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org 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: , X-List-Received-Date: Tue, 02 Mar 2021 11:26:10 -0000 * Natalia Saiapova via Gdb-patches [2020-10-09 13:27:15 +0200]: > After an inferior call is finished, the target is unregistered from > the event loop. However, if the inferior call has happened during > the condition evaluation, we still want to get `stop` events from > other threads in `wait_one`. So, register the target back. My first question after reading this patch and the commit message is, why don't we stop the unregistering for the case when we shouldn't unregister. There's probably a really good answer, and you probably have all the knowledge in your head.... but the commit message is a little terse. Could you explain why it's better to let GDB do the wrong thing and then patch it up, instead of just doing to right thing all along? Also, it feels like this change should have a test. Thanks, Andrew > > gdb/ChangeLog: > 2020-08-26 Natalia Saiapova > Tankut Baris Aktemur > > * infcall.c (run_inferior_call): In condition evaluation, > register the target back after the infcall. > > Co-authored-by: Natalia Saiapova > Co-authored-by: Tankut Baris Aktemur > > Signed-off-by: Natalia Saiapova > --- > gdb/infcall.c | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/gdb/infcall.c b/gdb/infcall.c > index 399b1724ea2..0b0226f8e82 100644 > --- a/gdb/infcall.c > +++ b/gdb/infcall.c > @@ -667,6 +667,9 @@ run_inferior_call (struct call_thread_fsm *sm, > > call_thread->control.in_infcall = saved_in_infcall; > > + if (call_thread->control.in_cond_eval && target_can_async_p ()) > + target_async (true); > + > return caught_error; > } > > -- > 2.17.1 > > Intel Deutschland GmbH > Registered Address: Am Campeon 10-12, 85579 Neubiberg, Germany > Tel: +49 89 99 8853-0, www.intel.de > Managing Directors: Christin Eisenschmid, Gary Kershaw > Chairperson of the Supervisory Board: Nicole Lau > Registered Office: Munich > Commercial Register: Amtsgericht Muenchen HRB 186928 >