From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id 13vMORFJn2qUpjUAWB0awg (envelope-from ) for ; Mon, 07 Sep 2026 19:30:25 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=simark.ca; s=mail; t=1788823825; bh=wiA2f2TvJU9wixPqpeZzAlapXIwMEXFK9w5f3skBN+4=; h=Date:Subject:To:Cc:References:From:In-Reply-To:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: From; b=OJjw3bJZZPSbcUBJqHvhAcZJnPI9lkGeQJtHB0A4rCKkBRNGEqEthyDoQC26W5fIE fsNkiMXSui8B3ONUDTvN/ldTfIzEckrS/XKM4xDUE0vrHK39t+Vvq4ir4zjdEM9KvX s96J9e4GYO2M3ezbvzMBwTchB7SJ9DPGIo9blni0= Received: by simark.ca (Postfix, from userid 112) id D0C2E1E09E; Mon, 07 Sep 2026 19:30:25 -0400 (EDT) X-Spam-Checker-Version: SpamAssassin 4.0.1 (2024-03-25) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-5.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 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=G51LRRLd; 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 CD2751E033 for ; Mon, 07 Sep 2026 19:30:24 -0400 (EDT) Received: from vm01.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 92AC248F8A42 for ; Mon, 7 Sep 2026 23:30:23 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 92AC248F8A42 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=G51LRRLd Received: from simark.ca (simark.ca [158.69.221.121]) by sourceware.org (Postfix) with ESMTPS id 154DE48F90FB for ; Mon, 7 Sep 2026 23:29:59 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 154DE48F90FB 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 154DE48F90FB Authentication-Results: sourceware.org; arc=none smtp.remote-ip=158.69.221.121 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1788823799; cv=none; b=bySjZ/hBuG+Jl0a9wEM3SilYioK1GugBBSSw5jnYsj94Cx1LJVNHblPVXk2atDrJyB2OeNYWsx6o99AgeeHtDXiB+4hPZ594LVIcs1iP1aPt1JKhQBtnQMhuZZuOstnlmF/v9/yBAENni4PK7HCDYfLeIgoacEtT2Rbg+ueE1Mw= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1788823799; c=relaxed/simple; bh=wiA2f2TvJU9wixPqpeZzAlapXIwMEXFK9w5f3skBN+4=; h=DKIM-Signature:Message-ID:Date:MIME-Version:Subject:To:From; b=jsUR+jGoST6q6HB9VpGTUMBZOX4FICJZNPvTTCPgDWbwNkLQgUwL3xH09gdzaU3mL2lar0e98HfcufzR+mSAxIdTDrEHclH/h7zvDmCWznRgEpA48Q3zaDYTbaillChSM7tBIEW6cuQgoLW7LUBC0OIJaagyefaaw5B9+s/l0DU= ARC-Authentication-Results: i=1; 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=G51LRRLd DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 154DE48F90FB DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=simark.ca; s=mail; t=1788823797; bh=wiA2f2TvJU9wixPqpeZzAlapXIwMEXFK9w5f3skBN+4=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=G51LRRLdrvuoypcuoUIb3/79Urn+oPbK7G14b2IqnUiDDpXqrIigOx1rdM1R2Jrz2 ngG5VsLrO2m0tahRk6H0gazQjcdxdk5YQkcbjnp1/JzpZDhi1ptrEagq7FwiEGL7vN UDgC1I70tBp+Uyqe/7kLqPRKCQcbNd9V03fLWfd8= Received: by simark.ca (Postfix) id 7827B1E033; Mon, 07 Sep 2026 19:29:57 -0400 (EDT) Message-ID: Date: Mon, 7 Sep 2026 19:29:56 -0400 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] gdb/amdgpu: Fix accessing GPU global memory To: Pedro Alves , gdb-patches@sourceware.org Cc: "Six, Lancelot" References: <20260907221545.3817530-1-pedro@palves.net> Content-Language: en-US From: Simon Marchi In-Reply-To: <20260907221545.3817530-1-pedro@palves.net> 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-09-07 18:15, Pedro Alves wrote: > Now that multi solib provider support is in, the gdb.rocm/ tests > should work on Windows, in theory. Turns out they still don't. GDB > is now able to discover GPU code objects, but still fails to stop at > GPU breakpoints. > > The reason is that accessing GPU global memory is not working on > Windows. It fails with STATUS_ERROR_INVALID_LANE_ID, like so: > > [amd-dbgapi-lib] amd_dbgapi_code_object_get_info (code_object_id=code_object_1 <"memory://5268#offset=0x90e9850&size=47824">, query=CODE_OBJECT_INFO_URI_NAME, value_size= > 8, value=0x73739feee0) { > [amd-dbgapi-lib] callback: allocate_memory (42) { > [amd-dbgapi-lib] callback: } allocate_memory = 0x1f82fdcc110 (took 0.011000 ms) > [amd-dbgapi-lib] } amd_dbgapi_code_object_get_info = STATUS_SUCCESS, *value="memory://5268#offset=0x90e9850&size=47824"@000001f82fdcc110 (took 0.633000 ms) > [amd-dbgapi-lib] amd_dbgapi_read_memory (process_id=process_1, wave_id=WAVE_NONE, lane_id=0, address_space_id=address_space_1 , segment_address=0x90e9850, value_s > ize=47824@00000073739fde78, value=0x1f8309246b0) { > [amd-dbgapi-lib] } amd_dbgapi_read_memory = STATUS_ERROR_INVALID_LANE_ID (took 0.024000 ms) > > We get STATUS_ERROR_INVALID_LANE_ID because we passed down > AMD_DBGAPI_WAVE_NONE, and in that case dbgapi enforces that the caller > pass down AMD_DBGAPI_LANE_NONE for lane. > > From dbgapi/src/memory.cpp: > > xfer_memory (amd_dbgapi_process_id_t process_id, amd_dbgapi_wave_id_t wave_id, > ... > if (wave != nullptr) > { > ... > } > else if (wave_id != AMD_DBGAPI_WAVE_NONE) > { > THROW (AMD_DBGAPI_STATUS_ERROR_INVALID_WAVE_ID); > } > else if (lane_id != AMD_DBGAPI_LANE_NONE) > { > /* wave_id is WAVE_NONE and lane_id != LANE_NONE. */ > THROW (AMD_DBGAPI_STATUS_ERROR_INVALID_LANE_ID); <<<<<<<<<< HERE > } > ... > > Actually, all the GPU global accesses currently fail on Linux too! > The logs show the exact same STATUS_ERROR_INVALID_LANE_ID all over the > place. It just so happens to be papered over by accident there -- > when accessing memory via amd-dbgapi-target fails, the core of GDB > will try the target beneath in the target stack (the process stratum > layer), and that (linux-nat) will work, because unlike on Windows, on > Linux we have unified memory so /proc/pid/mem successfully accesses > the GPU memory. > > Fix this by passing AMD_DBGAPI_LANE_NONE when wave_id is > AMD_DBGAPI_WAVE_NONE. We don't have proper lane support yet, so when > wave_id is a valid wave, continue accessing lane 0. > > Tested on x86_64-pc-linux-gnu and x86_64-pc-windows-msvc (with pending > testsuite patches). > > gdb.rocm/ tests now work on Windows, and most pass cleanly. > > Change-Id: I7dd53bc0a6ffdfaca71e70772562cc7ac1362f05 > --- > gdb/amd-dbgapi-target.c | 8 ++++++-- > 1 file changed, 6 insertions(+), 2 deletions(-) > > diff --git a/gdb/amd-dbgapi-target.c b/gdb/amd-dbgapi-target.c > index 45ad8f98a92..93207a8fdd2 100644 > --- a/gdb/amd-dbgapi-target.c > +++ b/gdb/amd-dbgapi-target.c > @@ -769,16 +769,20 @@ amd_dbgapi_target::xfer_partial (enum target_object object, const char *annex, > amd_dbgapi_wave_id_t wave_id = (ptid_is_gpu (inferior_ptid) > ? get_amd_dbgapi_wave_id (inferior_ptid) > : AMD_DBGAPI_WAVE_NONE); > + /* dbgapi requires LANE_NONE when wave is WAVE_NONE. */ > + amd_dbgapi_lane_id_t lane_id = (wave_id != AMD_DBGAPI_WAVE_NONE > + ? 0 > + : AMD_DBGAPI_LANE_NONE); > > size_t len = requested_len; > amd_dbgapi_status_t status; > > if (readbuf != nullptr) > - status = amd_dbgapi_read_memory (process_id, wave_id, 0, > + status = amd_dbgapi_read_memory (process_id, wave_id, lane_id, > AMD_DBGAPI_ADDRESS_SPACE_GLOBAL, > offset, &len, readbuf); > else > - status = amd_dbgapi_write_memory (process_id, wave_id, 0, > + status = amd_dbgapi_write_memory (process_id, wave_id, lane_id, > AMD_DBGAPI_ADDRESS_SPACE_GLOBAL, > offset, &len, writebuf); I don't know if you want to wait for Lancelot's approval, but fwiw it LGTM, and trivial enough. Approved-By: Simon Marchi Simon