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 9CCAC385800C for ; Fri, 15 Mar 2024 15:06:51 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 9CCAC385800C 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 9CCAC385800C 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=1710515214; cv=none; b=kGiJIrSir/heyLR8ko6npQr4wUgjhg2e3Zec9d2z4K617g7CkRxwbR5NAaM8eokrjLx5MHKWlOo34r0YUOKqkyAeKcwOhmULPJ2+HZ0uJpbwnWHiZ0IRUutiB2U/Z35YO4TljvI+zhw3sazSg7hB4oSd4T5MmUw+P5U4aBuEQow= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1710515214; c=relaxed/simple; bh=rmpZJJTqE4zHQxnRiZPciOSZivFySuCcOvkCP1VUrxw=; h=DKIM-Signature:Message-ID:Date:MIME-Version:Subject:To:From; b=Fb0A2sewUGE1OrB0Dn90u+j+eoO6D08Wnwqtal99nf2yO98CJtkYgzrSmxRxZqxfwwn1R35XC8gkH6IdiUM3/z5BL4qeTvweUYJSzSlOHC946QRJv0yTT5ccMHDZOfhTCIzQ15QsTZfpu/dB/97MqPxZUwLBbwWz9O/uVpIYhy0= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=simark.ca; s=mail; t=1710515210; bh=rmpZJJTqE4zHQxnRiZPciOSZivFySuCcOvkCP1VUrxw=; h=Date:Subject:To:References:From:In-Reply-To:From; b=vVz06Yc92AXJn9y5qd+sDDaGoKTfvGvA+YxGpzqrGO+3slGqebLUVWlE0yCdzEWi5 pLMhbDYbdvmPfCm3Tv/8wNEO6IX+DMOgSXDrNOWgQMf0IGl22zxQON41L5N063Bv/N zR1UApdkiYKzFsDBDuR7lUvxEVcbXQiNGH3TBfcU= Received: from [10.0.0.170] (modemcable238.237-201-24.mc.videotron.ca [24.201.237.238]) (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 85E6C1E01D; Fri, 15 Mar 2024 11:06:50 -0400 (EDT) Message-ID: Date: Fri, 15 Mar 2024 11:06:50 -0400 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] gdb: iterate over targets, not inferiors, to commit resumed Content-Language: fr To: "Aktemur, Tankut Baris" , "gdb-patches@sourceware.org" References: <20240301155259.1507053-1-tankut.baris.aktemur@intel.com> <9c467373-6960-42f8-8bfc-a1b94c9df70a@simark.ca> <50778bd5-64a3-47bb-bdbf-60c86e5a51a3@simark.ca> From: Simon Marchi In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-4.7 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/12/24 15:05, Aktemur, Tankut Baris wrote: >> I recently thought about this scenario, imagine we have the following >> inferiors: >> >> | inf1 | inf2 >> target stratum | my-thread-target | >> process stratum | linux-nat | linux-nat >> >> Imagine the thread target is meant to pull events from the linux-nat >> target below and translate them to some higher level events about >> userspace thread. When infrun pulls events, it selects a random >> inferior and calls target_ops::wait with minus_one_ptid. What if >> inferior 2 is selected, and linux-nat returns an event about inferior 1, >> that was meant to be processed by my-thread-target? > > Would it make sense to fetch the events per inferior using the inferior's > pid as the filter ptid? Is there a fundamental limitation against doing that? When I talked to Pedro about this issue, he came up with the same suggestion. It sounds good in theory, but I'm wondering if there are cases where calling with ptid == minus_one_ptid is needed, because the target wants to report an event for a ptid that isn't known to the core yet. Simon