From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca (simark.ca [158.69.221.121]) by sourceware.org (Postfix) with ESMTPS id 0BDA63858C74 for ; Fri, 1 Mar 2024 19:02:19 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 0BDA63858C74 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=simark.ca Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=simark.ca ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 0BDA63858C74 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=158.69.221.121 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1709319742; cv=none; b=W/yYJ2sMrT/l0a5tnxUxd0OCkEomCW39WQIRlier/Dl7Jd/z1Qr7X+PG1274nGTfRL67q3qEOyAnC7OotH3j6TC9Q0gzvOYrLvsdixNTmGgHIZMj6z7hCko8aLT6mAdYQIsf4FAy4S6d9u7ERSG+B2JAmV64w6ZvGcpWh9538+0= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1709319742; c=relaxed/simple; bh=04HuOxxTSnBJhbLRwpq4HBpJC35tSTMqdPiWu8ZdXNw=; h=DKIM-Signature:Message-ID:Date:MIME-Version:Subject:To:From; b=H019SWO2I847hQWUZ8rwDmIjdAPG1RjBSOlM6mgLhKmdQjoRL99TFjL1w60JGTra4bsYT56uCk28kW76ueYHsFziaYzrLj2/6xs7frxADQiLs6zRkgAT1+NSK7yj4uogh310FJwT39cPeaFdIjzqi4P0V3d9IPYj8cMMg86umyw= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=simark.ca; s=mail; t=1709319738; bh=04HuOxxTSnBJhbLRwpq4HBpJC35tSTMqdPiWu8ZdXNw=; h=Date:Subject:To:References:From:In-Reply-To:From; b=VPwA0/nUi9wfrU931O5x9LO6ug0BzCNlSMqgdRdmLtTZCIDGsAhQ3GjCfxynlg8NO Vp0c1Fc/wbVgzl/cGNRCYWWai8pW6dRnLWGLL9/Irc8ZvB+Qs+25XROHyb0P8p05Uj ydtgNXjhkGmmGuRyRsLNV5pcd4z2ERwt3pBiIu0Y= Received: from [172.16.0.192] (192-222-143-198.qc.cable.ebox.net [192.222.143.198]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature ECDSA (prime256v1) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPSA id 4EA931E030; Fri, 1 Mar 2024 14:02:18 -0500 (EST) Message-ID: <9c467373-6960-42f8-8bfc-a1b94c9df70a@simark.ca> Date: Fri, 1 Mar 2024 14:02:17 -0500 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] gdb: iterate over targets, not inferiors, to commit resumed Content-Language: fr To: Tankut Baris Aktemur , gdb-patches@sourceware.org References: <20240301155259.1507053-1-tankut.baris.aktemur@intel.com> From: Simon Marchi In-Reply-To: <20240301155259.1507053-1-tankut.baris.aktemur@intel.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-4.8 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,SPF_HELO_PASS,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: On 3/1/24 10:52, Tankut Baris Aktemur wrote: > When committing resumed threads of targets, iterate over targets, not > inferiors, so that we don't call commit_resumed multiple times for > targets that have multiple inferiors. This gives more concise code. > > Similarly, iterate over targets when setting the commit_resumed_state > of targets. > > No behavioral change is expected or intended with this patch. Hi Baris, The change in maybe_call_commit_resumed_all_targets might not play well with the amd-dbgapi target (and is probably the reason this code was written like this in the first place). Right now, it's kind of a hack, but the amd-dbgapi target sits on top of the linux-nat target, in the arch stratum layer. It intercepts some target calls, and really acts as a second process target for the inferior, without being an actual process_stratum_target. Imagine you have two inferiors, one debugging a plain Linux program and the other a program using the GPU. The target stacks will look like: inf1 inf2 arch stratum: amd-dbgapi process stratum: linux-nat linux-nat By iterating only on process stratum targets, commit_resumed will only be called on inferior 1, and therefore the amd-dbgapi target will never see it. The GPU threads will not effectively be resumed. Our plan is to try to make amd-dbgapi a proper process_stratum_target and allow inferiors to have more than one process target, in which case your change would probably be fine. We haven't started on that front yet, unfortunately. The change in maybe_set_commit_resumed_all_targets is probably fine though. Simon