From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id 4oR0EyopDmqg8woAWB0awg (envelope-from ) for ; Wed, 20 May 2026 17:35:38 -0400 Received: by simark.ca (Postfix, from userid 112) id 39D2C1E098; Wed, 20 May 2026 17:35:38 -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.3 required=5.0 tests=ARC_SIGNED,ARC_VALID,BAYES_00, 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 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 51ADF1E024 for ; Wed, 20 May 2026 17:35:37 -0400 (EDT) Received: from vm01.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id BA1BD4BB5925 for ; Wed, 20 May 2026 21:35:35 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org BA1BD4BB5925 Received: from mail-wr1-f52.google.com (mail-wr1-f52.google.com [209.85.221.52]) by sourceware.org (Postfix) with ESMTPS id 33F794BA543C for ; Wed, 20 May 2026 21:35:12 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 33F794BA543C Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=palves.net Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 33F794BA543C Authentication-Results: sourceware.org; arc=none smtp.remote-ip=209.85.221.52 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1779312912; cv=none; b=nbbXcx+Ps15qFA+Ug8CDKrcTyB8yJkZg2CdU2qL0VXgLIZXTGM/XEEOGTmbiiVWELfNejJLs9OSknv17AEy/Mw8z5LjDARkJO6It9i0QTA7LzW2yMobfMcPql6xUzjpsoJqoj/0X7IdsTbyZ/2GVxniVCOTW6+q6+4cpwnjry0g= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1779312912; c=relaxed/simple; bh=En8ozYh96CpxQMhfRxLRk1pXd3GS2iNCkaUO6OJG/6s=; h=Message-ID:Date:MIME-Version:Subject:To:From; b=inwM5lmVbY0GbacJYVD/dtbfd2pzLRgdi2vsL8nIJRlAFtsZIHIN3jN87LQRf0bA/lNcmxPZ0IipcG78tYhGhA/jd15TBuIo0+hNy3IcLhskiGDr9XZRYz4yWaD7Oozjmwbli5l2Fe99eVuyu5y1UyRkh64nPbTB49t/Yn64Gec= ARC-Authentication-Results: i=1; sourceware.org DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 33F794BA543C Received: by mail-wr1-f52.google.com with SMTP id ffacd0b85a97d-43d76dd4ee8so2241524f8f.2 for ; Wed, 20 May 2026 14:35:12 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1779312911; x=1779917711; h=content-transfer-encoding:in-reply-to:content-language:from :references:cc:to:subject:user-agent:mime-version:date:message-id :x-gm-gg:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=0sf/wYRLoZDgmrKZro7auYYVZ6ibYHvIlgKJILlyESg=; b=A2Cb2+q8RQiOj9HRW0da1klqj4tLun0lFQQNpnysKfeNd74bhQEfWlVqSzVbCUPkHJ azsPeZxFoLIO/tHyZ+vD/fvuLWzp74sL23NumygMbjtFcrhfSO4Q8rWEd1K8bOO/jKst o1j8B9dbGE48AWki3LlOVi9wD94ec6uBH81zqJqdh9arHksGt5Ru6m9rRQ8oz4DpA/yE hlGTOdvVwls485wfmf1/Z95DXRWTyArQAQGe3hCuxp1lyCJZwxcOm8xs17FHPSIHcabO IoQ7+LkkisWf3qCCcsQF0I6XgAAtsdj+kZq3ZcmKjlmEY36xkPliSqD881ScQeLCwes5 xJZA== X-Forwarded-Encrypted: i=1; AFNElJ/T2XMt+EWvFLXvZ1DsQiLo3bQeVvmSX//K1HedHOTd2POLJpopMKXomV787EaQ30YbZnsQvwA0xd8cRw==@sourceware.org X-Gm-Message-State: AOJu0YzJGldpK1mXcKOvBK04AA+/7/b+Y4y9oc/hGbNIdOyNHAwQeM+p YHEgT2MR0Xd1XR86ItfDcbN1YBJ1HSWR8ggzXLTCFBlBQI0O+jgNB9qW X-Gm-Gg: Acq92OGOnGdAv5yApJZpLZbII6Q5JGdf+Ivt0/Q3r6YE7SHuu0SD6cpjfWQcoW6toRA cm/TYOT8WSKUMq+akJJaGiQEOIJExDt26W5o5P9JFp9S5AMb2Fe2+Bpi1Ddk2RxtnvMbXM0LIag VX5pW0oU8MlHkd/K7M4eRXZhj1hNj24hwsoB4VUUPh6u48AAB7z9fdtDNqBAzXQ4/zpyVDuLlw9 Zc64eJahMc2iPSWg0rujIUkq05Kreqzw4bpjXtGm4wJMbFg5HIRfeW1+6sayZRxxqXvBoYOFtPM uoYyVVzYPKRDWqGNUeA3ZVA24RBD0XO3b4Ynsb/TRXWb3UOmDaDbU0T5VQE4A43/jRRqGEFG/5I 9zOfmJEYfrsAjwbrqNcJ75N5UahUmkUGaCwgPcUMNNpvIubhgwq78PwSNjJt4zZEc18tFMddjGD 8DmRBDMXPWvnr+tsEMX532+auBWU54E0J4fLrJW11t3ZVlszmAo1tRPCxrbVcjmHtoGw== X-Received: by 2002:a05:6000:1448:b0:43c:ef4f:79dc with SMTP id ffacd0b85a97d-45ea37bd64dmr119220f8f.8.1779312910455; Wed, 20 May 2026 14:35:10 -0700 (PDT) Received: from ?IPV6:2001:8a0:fae3:2600:b301:95ce:ed8f:389e? ([2001:8a0:fae3:2600:b301:95ce:ed8f:389e]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-45da0a19a0csm54239886f8f.20.2026.05.20.14.35.09 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 20 May 2026 14:35:10 -0700 (PDT) Message-ID: Date: Wed, 20 May 2026 22:35:06 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] gdb/solib-rocm: add support for file URI on Windows To: Lancelot SIX , gdb-patches@sourceware.org Cc: Tankut Baris Aktemur , Simon Marchi References: <20260520172256.629890-1-lancelot.six@amd.com> From: Pedro Alves Content-Language: en-US In-Reply-To: <20260520172256.629890-1-lancelot.six@amd.com> 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-20 18:22, Lancelot SIX wrote: > Current GDB does not really AMDGPU debugging on Windows (there are still Some word missing, I guess "support". > a couple of missing necessary pieces), but this patch can still be > applied upstream and will eventually be needed. I have tested this > patch on top of the downstream ROCgdb windows branch[1]. I have also > tested this patch on Linux + gfx1031 on top of master to ensure this > causes no regression. > > [1] https://github.com/ROCm/ROCgdb/tree/amd-temp-windows > --- > gdb/solib-rocm.c | 16 ++++++++++++++++ > 1 file changed, 16 insertions(+) > > diff --git a/gdb/solib-rocm.c b/gdb/solib-rocm.c > index d9ae4294c98..d8d36d2f3c0 100644 > --- a/gdb/solib-rocm.c > +++ b/gdb/solib-rocm.c > @@ -30,6 +30,7 @@ > #include "solib.h" > #include "solib-svr4.h" > #include "symfile.h" > +#include "filesystem.h" > > namespace { > > @@ -586,6 +587,21 @@ rocm_bfd_iovec_open (bfd *abfd, inferior *inferior) > > if (protocol == "file") > { > + /* Windows absolute file path can be encoded with a leading "/" in > + the URI: "file:///C:/Users/foo/bar". This scheme is not strictly > + standard but widely used (see RFC 8089 Appendix E.2). I think this comment has it backwards. "file:///C:/Users/foo/bar" is actually the standard form per RFC 8089. It's the regular "file:///" syntax where the authority is empty and the path-absolute happens to begin with a drive letter, so you get a leading / before "C:". The non-standard short form discussed by RFC 8089 Appendix E.2 is: file:c:/path/to/file ... with no "//" and no leading slash before the drive. That same appendix states: 'URIs of the form "file:///c:/path/to/file" are already supported by the "path-absolute" rule.' These are standard. The code is still correct, though. Once you decode the standard URI you do get "/C:/Users/foo/bar", and you do need to strip the leading / on DOS-based filesystems to turn it back into a real Windows path. That's just an artifact of the URI grammar requiring a path-absolute (must start with /). See RFC 8089 Appendix D.2. It's not because the URI form is non-standard. I'd suggest rewording the comment to something like: /* A Windows absolute file path is encoded in a file: URI with a leading "/" before the drive letter: "file:///C:/Users/foo/bar". See grammar in RFC 8089 Section 2, the path-absolute production requires the leading "/". 'path-absolute' is defined by RFC 3986 Section 3.3. After decoding, decoded_path would be "/C:/Users/foo/bar", which is not a valid Windows path. Drop the leading "/" as a normalization step. */ Otherwise LGTM. Approved-By: Pedro Alves Thanks, Pedro Alves