From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id /8zGM58W+mkO/BYAWB0awg (envelope-from ) for ; Tue, 05 May 2026 12:11:11 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=simark.ca; s=mail; t=1777997471; bh=NXgWGS0lJf2T1HOOaZTfj0gd3KMbRjf8vyS4AVHEK4E=; h=Date:Subject:To:Cc:References:From:In-Reply-To:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: From; b=dswuznb9ohVbt+XKSnoglzPs3UlfoiMd7R11Llp4pr47iOf4s14GnEQUqGWP/TL33 8TiSG8xRS8C7iRmUo4IkbdU9prLEj62rXKg2bNiLGzbX7Ez9505ptnBgdBepSPdbqv dYs4aplRBmyPKHMrWoPD97j+bKW3AlUS4CjOur1U= Received: by simark.ca (Postfix, from userid 112) id AE6131E0BA; Tue, 05 May 2026 12:11:11 -0400 (EDT) X-Spam-Checker-Version: SpamAssassin 4.0.1 (2024-03-25) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=ARC_SIGNED,ARC_VALID,BAYES_00, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI, RCVD_IN_DNSWL_MED,RCVD_IN_VALIDITY_CERTIFIED_BLOCKED, RCVD_IN_VALIDITY_RPBL_BLOCKED,RCVD_IN_VALIDITY_SAFE_BLOCKED autolearn=ham autolearn_force=no version=4.0.1 Authentication-Results: simark.ca; dkim=pass (1024-bit key; unprotected) header.d=simark.ca header.i=@simark.ca header.a=rsa-sha256 header.s=mail header.b=NYvViyXV; dkim-atps=neutral Received: from vm01.sourceware.org (vm01.sourceware.org [38.145.34.32]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange x25519 server-signature ECDSA (prime256v1) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPS id 097951E067 for ; Tue, 05 May 2026 12:11:11 -0400 (EDT) Received: from vm01.sourceware.org (localhost [127.0.0.1]) by sourceware.org (Postfix) with ESMTP id 8BEBB4BA23C5 for ; Tue, 5 May 2026 16:11:10 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 8BEBB4BA23C5 Authentication-Results: sourceware.org; dkim=pass (1024-bit key, unprotected) header.d=simark.ca header.i=@simark.ca header.a=rsa-sha256 header.s=mail header.b=NYvViyXV Received: from simark.ca (simark.ca [158.69.221.121]) by sourceware.org (Postfix) with ESMTPS id 8B2084BA2E14 for ; Tue, 5 May 2026 16:10:36 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 8B2084BA2E14 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 8B2084BA2E14 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=1777997436; cv=none; b=w9IArRXEprIn6i20S5r5phOV1LkkGRlevk1LENciG5pHkuyoFVhvJajODglnhJxm5ZSFTuE1ukXibk+6/x1LWTsGkvK6r7OYeDnUPed8sFpR9zlmZdoHta3FoANSHaifXZxEeStkVFZaLT+MAqLbj25Edc4TGKaHBIpESELMnOU= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1777997436; c=relaxed/simple; bh=NXgWGS0lJf2T1HOOaZTfj0gd3KMbRjf8vyS4AVHEK4E=; h=DKIM-Signature:Message-ID:Date:MIME-Version:Subject:To:From; b=N8kuueGqjzX6j4Q5pXEHS1Zr13W09v4552SrFo1n9FH1iuTg8h7+NAqrYlIg3uT14MzjxLz0GCdB6nef+rNssAP28S9g3etuHglwlaUexaCoHc2bO5R5NbFuS8+oLn0aP6RKQI78IVdqgzzZkqRNP1oAppcbo1Yd2fgj5dSssW0= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 8B2084BA2E14 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=simark.ca; s=mail; t=1777997434; bh=NXgWGS0lJf2T1HOOaZTfj0gd3KMbRjf8vyS4AVHEK4E=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=NYvViyXVjyxTgf2IJIk5UFmpqkBZ/HVC4huXO0eipg8bb9+moSRgCKGJke40vEhCS mbgOp03JqNN5M/poCVgbkOEH1fqufptSHRsSg1qm9ogdF280Sa759WACzuJMSLUGOl nA84x7RLPH1K0y33WxlwOrL5jBQNBQIGyTVB8LJ4= Received: by simark.ca (Postfix) id 83E7D1E067; Tue, 05 May 2026 12:10:34 -0400 (EDT) Message-ID: <38d58eb1-8127-49d0-8697-6e1feb5cbf07@simark.ca> Date: Tue, 5 May 2026 12:10:34 -0400 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] gdb: use correct target in notify_thread_exited() To: "Metzger, Markus T" Cc: "gdb-patches@sourceware.org" References: <20260504071636.1571615-1-markus.t.metzger@intel.com> <20260504071636.1571615-6-markus.t.metzger@intel.com> <4e284db3-0061-4245-bf0d-7a14a7afe073@simark.ca> Content-Language: en-US From: Simon Marchi In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.30 Precedence: list List-Id: Gdb-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: gdb-patches-bounces~public-inbox=simark.ca@sourceware.org On 2026-05-05 03:56, Metzger, Markus T wrote: >> This is unfortunately not correct, because target calls (annoyingly IMO) >> use the target stack of the current inferior to find the target beneath. >> If you are having to do this change, it means that this function is >> called for a thread of inferior A, while inferior B is the current one. >> What will happen is that you'll start with the top target of inferior A, >> but if that target calls "target_ops::beneath()" to delegate to the >> target beneath, that will jump to a target of inferior B. If the >> pid_to_str operation is handled by the top target of inferior A, it will >> work, but not in the general case. >> >> As of today, the only fix for that would be to temporarily switch >> inferior. > > Those scoped_restore_foo are everywhere. I tried to not rely on > global state and instead use the arguments passed to the function, > but I see now how this cannot work. Makes you wonder why we > even bother passing thread_info * and inferior *. Indeed, if a random function takes an inferior parameter but also requires that this inferior is the current one, it can be misleading. It makes you think that it is global-context-agnostic, while it is not. I try not to do this. I would say that this "target calls rely on current inferior's target stack" is the major blocker for continuing doing cleanups to pass context through parameters, rather than global variables. > I switch to the exited thread in v2. > >> I once made a prototype [1] of passing down the target stack explicitly to >> all target functions. It would be quite invasive, but I don't see any >> other solution if we want to lift that "target calls care about current >> inferior" limitation. >> >> [1] https://review.lttng.org/c/binutils-gdb/+/5627 > > It's every call to inferior_thread() and current_inferior(), too. I am not sure what you mean here, those are just simple getters. Simon