From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id EGbuOpP/RmjkKgcAWB0awg (envelope-from ) for ; Mon, 09 Jun 2025 11:36:51 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=simark.ca; s=mail; t=1749483411; bh=ik9OK+Xau7+rK7Pyb/sYfyzpdwvu+nYCm0g1mes7wPA=; h=Date:Subject:To:Cc:References:From:In-Reply-To:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: From; b=RxaLCx1op92aSDxNh09m5Xi4a39OLSAy3/TnWYfOwDfQW7zXO4JR2rl7cAIJo7JQL yAOgG6m7wJGkh+i+fdZATLbAy5eI6H0hdLMJzERUw8GcsQgOKaHwqYqCEFIX+3YJ+V Gi+GPXoyIUPnEzX4sFpsdBjD4PCo6GiUKYYdBhNY= Received: by simark.ca (Postfix, from userid 112) id DBE531E11C; Mon, 9 Jun 2025 11:36:51 -0400 (EDT) X-Spam-Checker-Version: SpamAssassin 4.0.1 (2024-03-25) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-9.1 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,RCVD_IN_VALIDITY_RPBL, RCVD_IN_VALIDITY_SAFE autolearn=unavailable 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=qWxJgeMY; dkim=pass (1024-bit key) header.d=simark.ca header.i=@simark.ca header.a=rsa-sha256 header.s=mail header.b=Bd7sx8no; dkim-atps=neutral Received: from server2.sourceware.org (server2.sourceware.org [8.43.85.97]) (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 3AA1D1E0C2 for ; Mon, 9 Jun 2025 11:36:51 -0400 (EDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id C097D382D467 for ; Mon, 9 Jun 2025 15:36:50 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org C097D382D467 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=qWxJgeMY; dkim=pass (1024-bit key) header.d=simark.ca header.i=@simark.ca header.a=rsa-sha256 header.s=mail header.b=Bd7sx8no Received: from simark.ca (simark.ca [158.69.221.121]) by sourceware.org (Postfix) with ESMTPS id BCA7D38302BD for ; Mon, 9 Jun 2025 15:36:15 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org BCA7D38302BD 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 BCA7D38302BD 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=1749483375; cv=none; b=Isv3C/lnsghKPahlP3GnX6+UG672Fg0EqjscXBfp3KB9qxIjCAKugyXGZ77lz32KQ2sQ232mvAqUUaM1p/KTtJNfLN38zFlELueIpyxAYqfpQuDzJMVedh4mJ7/h7YVUogzOuiPgBW56L9+IOCFNrHiIF+UjbhDGGxtTJsKOGrc= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1749483375; c=relaxed/simple; bh=ik9OK+Xau7+rK7Pyb/sYfyzpdwvu+nYCm0g1mes7wPA=; h=DKIM-Signature:DKIM-Signature:Message-ID:Date:MIME-Version: Subject:To:From; b=a2xfGFYtspYZl6KSj0gw1xDIBzYhp+lgWd4iVYmB+m6UJqGdFjKaOXtRxShs4mDWJ3owz8rtIdp4uP75thE83qaBKczRZbH7r5+dE9HMp4bcsMEN5vFlVoIbWuppoOyzAMctAyXvY+R+AF6cyWd4iQxiTHW46/DYZgQ6/XyDWU4= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org BCA7D38302BD DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=simark.ca; s=mail; t=1749483375; bh=ik9OK+Xau7+rK7Pyb/sYfyzpdwvu+nYCm0g1mes7wPA=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=qWxJgeMYeasT1QEroQm4huy5F4+o7Am4vVSDN9lL4myyYCgr0kElTPecH54r9E3xj bNLgLmVfZf4EMAw28qy9g8+tc2JqqfOspOWTMoG7zUPY/mpsno7ObvcCAVesmeLiUD fPDQCg8+w0wYEoOYvKv4YSo7GYiVAOVoGlISdAU0= Received: by simark.ca (Postfix, from userid 112) id 17CF81E11E; Mon, 9 Jun 2025 11:36:15 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=simark.ca; s=mail; t=1749483372; bh=ik9OK+Xau7+rK7Pyb/sYfyzpdwvu+nYCm0g1mes7wPA=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=Bd7sx8no7Ocz3PPWuvO4iwDhG1b99SdaLhmvwY5YA/ig/zId+vN75QtPVM3I09Csq lCX40qgoMVghgiD/WTju1/ePcG8bxFnN0/cxjFusGVYDlkcIrt02cUKPCvCAkxEBZ4 33wb4MEifdMhHV7Fb+N4EFFT0bTFGt0O9AlLfGMk= Received: from [172.16.0.192] (192-222-132-26.qc.cable.ebox.net [192.222.132.26]) (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 0EDE91E0C2; Mon, 9 Jun 2025 11:36:11 -0400 (EDT) Message-ID: <8208e143-0a70-4ac6-b913-3fcd26a34921@simark.ca> Date: Mon, 9 Jun 2025 11:36:11 -0400 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 3/5] gdb/amd-dbgapi: pass amd_dbgapi_inferior_info to process_event_queue To: Lancelot SIX , Simon Marchi Cc: gdb-patches@sourceware.org References: <20250605201657.418206-3-simon.marchi@efficios.com> <9e94ce1e-56dd-49d5-ac03-d61c2e3a677f@SATLEXMB04.amd.com> Content-Language: fr From: Simon Marchi In-Reply-To: <9e94ce1e-56dd-49d5-ac03-d61c2e3a677f@SATLEXMB04.amd.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit 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 6/6/25 7:00 AM, Lancelot SIX wrote: > On Thu, Jun 05, 2025 at 04:16:26PM -0400, Simon Marchi wrote: >> A following patch will make process_event_queue access a field of >> amd_dbgapi_inferior_info. Prepare for this by making >> process_event_queue accept an amd_dbgapi_inferior_info object, instead >> of a process id. >> >> Change-Id: I9adc491dd1ff64ff74c40aa7662fffb11bd8332b >> --- >> gdb/amd-dbgapi-target.c | 25 +++++++++---------------- >> 1 file changed, 9 insertions(+), 16 deletions(-) >> >> diff --git a/gdb/amd-dbgapi-target.c b/gdb/amd-dbgapi-target.c >> index 8fd8bcf5ae49..1ec20d1874ec 100644 >> --- a/gdb/amd-dbgapi-target.c >> +++ b/gdb/amd-dbgapi-target.c >> @@ -234,7 +234,7 @@ struct amd_dbgapi_inferior_info >> }; >> >> static amd_dbgapi_event_id_t process_event_queue >> - (amd_dbgapi_process_id_t process_id, >> + (amd_dbgapi_inferior_info &info, >> amd_dbgapi_event_kind_t until_event_kind = AMD_DBGAPI_EVENT_KIND_NONE); >> >> static const target_info amd_dbgapi_target_info = { >> @@ -564,8 +564,7 @@ amd_dbgapi_target_breakpoint::check_status (struct bpstat *bs) >> /* If the action is AMD_DBGAPI_BREAKPOINT_ACTION_HALT, we need to wait until >> a breakpoint resume event for this breakpoint_id is seen. */ >> amd_dbgapi_event_id_t resume_event_id >> - = process_event_queue (info->process_id, >> - AMD_DBGAPI_EVENT_KIND_BREAKPOINT_RESUME); >> + = process_event_queue (*info, AMD_DBGAPI_EVENT_KIND_BREAKPOINT_RESUME); >> >> /* We should always get a breakpoint_resume event after processing all >> events generated by reporting the breakpoint hit. */ >> @@ -1337,28 +1336,22 @@ event_kind_str (amd_dbgapi_event_kind_t kind) >> gdb_assert_not_reached ("unhandled amd_dbgapi_event_kind_t value"); >> } >> >> -/* Drain the dbgapi event queue of a given process_id, or of all processes if >> - process_id is AMD_DBGAPI_PROCESS_NONE. Stop processing the events if an >> - event of a given kind is requested and `process_id` is not >> - AMD_DBGAPI_PROCESS_NONE. Wave stop events that are not returned are queued >> - into their inferior's amd_dbgapi_inferior_info pending wave events. */ >> +/* Drain the dbgapi event queue of a given process_id. Stop processing the > > It reads odd to have process_id here, as we don't pass it as an explicit > parameter anymore. Could it say "a given inferior" instead? Yes, makes sense. > >> + events if an event of a given kind is requested (not AMD_DBGAPI_EVENT_NONE). >> + Wave stop events that are not returned are queued into their inferior's >> + amd_dbgapi_inferior_info pending wave events. */ > > My first intuition when reading this patch was "hey, the INFO param is > never modified, why not use a const ref". But eventually ,under > process_one_event, we'll grab a reference to the INFO and modify it to > stash stop events. > > Should this patch go one step further, and have the INFO passed to > process_one_event (this one can ensure the event's process_id matches > the INFO's process_id)? This would also save iterating over all > inferiors to find the one we are looking for. Oh, yes, that's a good idea. Or, we could just skip the AMD_DBGAPI_EVENT_INFO_PROCESS and AMD_DBGAPI_PROCESS_INFO_OS_ID calls altogether, since we know for which process the event is anyway. I will add this as a separate patch just after this one. Simon