From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id CF7FBmEWQ2ndCQYAWB0awg (envelope-from ) for ; Wed, 17 Dec 2025 15:45:21 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=simark.ca; s=mail; t=1766004321; bh=N3ygc/eJK5IvV1XfYjGS42baPwKJQsgUP2X5vEe+Wsk=; h=Date:Subject:To:Cc:References:From:In-Reply-To:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: From; b=Iy2hz/jFMyCRRCPf3H4BaR/Q+eQCASf2QIV6L9FE5vJ459JKbXAopC8Z6t+5KCybY SHgVF+6zFF5uB0qd2GL2ZxY0HgjdZMFFDL3f6nTMTL9G52FdbrUih+d3/lUkcpIUH1 0vIDpw9KKyJqS6Kf2XpE9kr0QEpIzAGkdv4j05FM= Received: by simark.ca (Postfix, from userid 112) id 08D3A1E0AB; Wed, 17 Dec 2025 15:45:21 -0500 (EST) 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=MXnFZTHo; 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 28C1B1E048 for ; Wed, 17 Dec 2025 15:45:20 -0500 (EST) Received: from vm01.sourceware.org (localhost [127.0.0.1]) by sourceware.org (Postfix) with ESMTP id A27814BA2E26 for ; Wed, 17 Dec 2025 20:45:19 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org A27814BA2E26 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=MXnFZTHo Received: from simark.ca (simark.ca [158.69.221.121]) by sourceware.org (Postfix) with ESMTPS id E9A954BA2E05 for ; Wed, 17 Dec 2025 20:44:55 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org E9A954BA2E05 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 E9A954BA2E05 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=1766004296; cv=none; b=fXKmHqm0NE/c21rggVn/ef8aTV53+4LNqdaxn1ydlDPWTf9xTb3ESfRF3LXoV4BGarzW0ORSjzg/xtIf38ZALK5U962upgY8z1aUf85ub9hzSEo4alPLMc4Z2nAFcxoD/K4wiJDeJZV7o3tE+YMFCJ064aE2OyfC3tkiyk21NCU= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1766004296; c=relaxed/simple; bh=N3ygc/eJK5IvV1XfYjGS42baPwKJQsgUP2X5vEe+Wsk=; h=DKIM-Signature:Message-ID:Date:MIME-Version:Subject:To:From; b=JdYfRC6OsuRdfzEt0RxrAUHWykFN427x9UPotqLDZDUSMYXNwGHV7PjEdznTAs/8J0lKlfacCP31ALRXBLgsSe1TcCS23oItQ/kmKcLtzJZTbphWu8UYlQgsihJwvbFBddxQou3SYtemqW1BNFGsgw1BuL1yyfI/zDcIR2V+YbE= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org E9A954BA2E05 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=simark.ca; s=mail; t=1766004295; bh=N3ygc/eJK5IvV1XfYjGS42baPwKJQsgUP2X5vEe+Wsk=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=MXnFZTHoeoDsURvjl4CjZnK6VhwTYYAUGoYuScfxvTfz2sfcxPrgtvgYikb8E0UQq irMlkm4Rng/Bu30nHGty9UJsk9YLYraGJW12GSj/SKnY4zKDuUYbqmoFL6sXHiX9KL T6vVAa6S80H0nrdoZ7s9LvUx2EDQP59pF/RFugtQ= Received: by simark.ca (Postfix) id 4E7041E048; Wed, 17 Dec 2025 15:44:55 -0500 (EST) Message-ID: Date: Wed, 17 Dec 2025 15:44:54 -0500 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v3 12/44] gdb, infrun, ze: allow saving process events To: "Metzger, Markus T" Cc: "Aktemur, Tankut Baris" , "gdb-patches@sourceware.org" References: <20250801-upstream-intelgt-mvp-v3-0-59ce0f87075b@intel.com> <20250801-upstream-intelgt-mvp-v3-12-59ce0f87075b@intel.com> <8995a60f-fa36-4de7-ba91-8319c0b56ae2@simark.ca> <4f129860-8182-487e-81fc-53de4e3b1256@simark.ca> Content-Language: fr 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 12/17/25 4:30 AM, Metzger, Markus T wrote: >>>>> From: Markus Metzger >>>>> >>>>> When a process stop reply is encountered during stop_all_threads (), a >> new >>>>> thread with the process' ptid is created and the waitstatus is saved in >>>>> that thread. The effect is that we have a thread with a process ptid and >>>>> we dropped the event. >>>>> >>>>> Save the waitstatus in the inferior, prevent that inferior from resuming, >>>>> and return it on the next wait. >>>> >>>> Can you clarify what a process-wide event is? Are there instances where >>>> a target returns that today, or is something new with intelgt? >>> >>> This is something new with IntelGT. An example would be a module load >> event. >> >> Can you point me where this process-wide module load event is added in >> the series? All I can find is the `U` stop reply, which can have >> `;library` appended, but I presume that `U` is a thread-specific event. > > This is added in > > [PATCH v3 35/44] gdbserver, ze, intelgt: introduce ze-low and intel-ze-low targets > > The intelgt remote target may also send > > [remote] Notification received: Stop:Up1.0;library Ok, so IIUC, it is an abuse (or re-purpose) of the U stop reply to be able to tack the "library" part? My understanding is that the original intent of the U stop reply is to say that we tried to stop a specific thread but that it isn't stoppable. On the other hand, returning a process-wide U does not mean "the whole process is unavailable", or does it? I assume it does not change the state of all threads in the process to "unavailable". Simon