From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id 6OuVG+MCpWkV+g8AWB0awg (envelope-from ) for ; Sun, 01 Mar 2026 22:24:19 -0500 Authentication-Results: simark.ca; dkim=pass (2048-bit key; unprotected) header.d=polymtl.ca header.i=@polymtl.ca header.a=rsa-sha256 header.s=oct2025 header.b=kNoE8bXE; dkim-atps=neutral Received: by simark.ca (Postfix, from userid 112) id 45E521E0DD; Sun, 01 Mar 2026 22:24:19 -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 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 606571E08D for ; Sun, 01 Mar 2026 22:24:17 -0500 (EST) Received: from vm01.sourceware.org (localhost [127.0.0.1]) by sourceware.org (Postfix) with ESMTP id A32784BA23CD for ; Mon, 2 Mar 2026 03:24:09 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org A32784BA23CD Authentication-Results: sourceware.org; dkim=pass (2048-bit key, unprotected) header.d=polymtl.ca header.i=@polymtl.ca header.a=rsa-sha256 header.s=oct2025 header.b=kNoE8bXE Received: from smtp.polymtl.ca (smtp.polymtl.ca [132.207.4.11]) by sourceware.org (Postfix) with ESMTPS id 448C04BA2E0E for ; Mon, 2 Mar 2026 03:23:42 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 448C04BA2E0E Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=polymtl.ca Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=polymtl.ca ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 448C04BA2E0E Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=132.207.4.11 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1772421822; cv=none; b=aC1TCjmUaGFYxaq8ToEii/EUSkSZ9GfoafhD7Ze+R0Htlal8k2A9MrLIa7l+yX/mATRzbV10k9PcjSYZCVH+CNMXH7mWjSCOTfE8qzl9B90t+exr74jX9mtgLrFQixQZb870Rv9rBgyPmYK7BBJOta2T34uZJdWNG0efJkY+Ui8= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1772421822; c=relaxed/simple; bh=5/cPb6nK/ZmOII3zoh9f/pSBcQmkJ6axOKKiZt4esP4=; h=DKIM-Signature:From:To:Subject:Date:Message-ID:MIME-Version; b=UC0/rA8onFt8Ywfl0HXQP+tJCXmRCxZJauFiqMD4ILFr1EMXuUPovsZsIc6wj8BDVlrNntcaXbtc9lVeL1bdOIricMzWbo8xWZtQnmpPhelIkV7j794tFnJpowWIW1RXgHUDDY7rEcqJTAPG4Cd/UZDUtITGEwkpzEAt/3+3mSU= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 448C04BA2E0E Received: from simark.ca (simark.ca [158.69.221.121]) (authenticated bits=0) by smtp.polymtl.ca (8.14.7/8.14.7) with ESMTP id 6223NZW4153482 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sun, 1 Mar 2026 22:23:40 -0500 DKIM-Filter: OpenDKIM Filter v2.11.0 smtp.polymtl.ca 6223NZW4153482 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=polymtl.ca; s=oct2025; t=1772421820; bh=CfU+k9MnP8sf2Ft26a55QR8LLcnXnxMCmRMZV/MWhkw=; h=From:To:Cc:Subject:Date:In-Reply-To:From; b=kNoE8bXEd8kLBhORu5G+gyQ8zCd++laPq3Rw+3KbO0+g8UjraHLVlaNJxld/CgzkG Zweu90n8b9zEEOqdlWvyMkOB3S5/o1UruouEcL+NTJLw6aMtVHGD5I2cibowFLQKOK doWlsig14USLR52REfg9kazF2S2Q4FvUSwEWm8GPDBVBf5W6ovurZQl4Vr4a+AAQVi loER1oskfadGvgx36tVITzV1Hrq6e17cRDO6EcnYz+a7paIF6v7CjUzbiPym3r5v/J R3yXajVdnERMyEyDwAlLeZGjUrwBsWt3/yODaz/MEa3FUmzF6q4PPeFn6iVPXVujdf lGEhe7wnbhGoQ== Received: by simark.ca (Postfix) id 15A831E08D; Sun, 01 Mar 2026 22:23:34 -0500 (EST) From: simon.marchi@polymtl.ca To: gdb-patches@sourceware.org Cc: Simon Marchi Subject: [PATCH v2] gdb/corelow: mark bytes unavailable when reading from unavailable mapping Date: Sun, 1 Mar 2026 22:23:05 -0500 Message-ID: <20260302032333.2287923-1-simon.marchi@polymtl.ca> X-Mailer: git-send-email 2.53.0 In-Reply-To: <20260228022059.117785-1-simon.marchi@efficios.com> References: <20260228022059.117785-1-simon.marchi@efficios.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Poly-FromMTA: (simark.ca [158.69.221.121]) at Mon, 2 Mar 2026 03:23:35 +0000 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 From: Simon Marchi New in v2: adjust some more tests, thanks to the Linaro CI for pointing this out. The main motivation for this change is to nicely support "lightweight" core files on ROCm (more on this below), but I think that the change also makes sense for regular core files. When handling a file mappings from a core file, the core target attempts to open the referenced file. If successful, the mappings from this file end up in the m_core_file_mappings vector. Otherwise, they end up in the m_core_unavailable_mappings vector. When trying to read from an address within an unavailable mapping, unless the executable target beneath is able to fulfill the request, the core target returns an error (TARGET_XFER_E_IO). This is from gdb.base/corefile.exp before the patch: (gdb) PASS: gdb.base/corefile.exp: accessing mmapped data in core file with coremmap.data removed x/8bd buf2ro 0x7f095a517000: Cannot access memory at address 0x7f095a517000 I think that this would be a good use case for the "unavailable" status. We know the memory was there at runtime, it's just not available during post-mortem debugging. That is the definition of "unavailable". After changing core_target::xfer_partial to report the bytes as unavailable, which this patch does, the same test now shows: (gdb) PASS: gdb.base/corefile.exp: accessing mmapped data in core file with coremmap.data removed x/8bd buf2ro 0x7f0250f52000: I would say that the output of the x command isn't great, but that is just a presentation issue. The original motivation for me to do this change is that we are working on lightweight GPU core dump support in ROCm. By default, the ROC runtime will dump all the memory allocated in the context of the crashing wave. This can result in absurdly big core dumps. With lightweight core dumps, the runtime only dumps a certain subset of the information that is considered essential. When trying to read a value from a segment of memory that was not dumped, I believe that it is natural to use the "unavailable" status. That is handled by this patch. In the following example, `d` is a kernel parameter of type `int *`. Its value was collected in the core dump, but the memory it points to, allocated with hipMalloc, was not. Before: (gdb) p data $1 = (int *) 0x78bf26e00000 (gdb) p data[5] ❌️ Cannot access memory at address 0x78bf26e00014 After: (gdb) p data $1 = (int *) 0x78bf26e00000 (gdb) p data[5] $2 = Note that the same concept exists on Linux with the minicoredumper project [1]. We could adjust the core target to act the same way when dealing with minicoredumps. [1] https://www.linutronix.de/minicoredumper/ Change-Id: I4df82ba4116e87545691facec0cb662c4b2b7797 --- gdb/corelow.c | 3 ++- gdb/testsuite/gdb.base/coredump-filter.exp | 2 +- gdb/testsuite/gdb.base/corefile.exp | 2 +- gdb/testsuite/gdb.debuginfod/corefile-mapped-file.exp | 2 +- 4 files changed, 5 insertions(+), 4 deletions(-) diff --git a/gdb/corelow.c b/gdb/corelow.c index a28a707c293a..57d05504fa3c 100644 --- a/gdb/corelow.c +++ b/gdb/corelow.c @@ -1470,7 +1470,8 @@ core_target::xfer_partial (enum target_object object, const char *annex, if (xfer_status == TARGET_XFER_OK) return TARGET_XFER_OK; - return TARGET_XFER_E_IO; + *xfered_len = len; + return TARGET_XFER_UNAVAILABLE; } } diff --git a/gdb/testsuite/gdb.base/coredump-filter.exp b/gdb/testsuite/gdb.base/coredump-filter.exp index c35a0334ff33..e2ce86d48e8a 100644 --- a/gdb/testsuite/gdb.base/coredump-filter.exp +++ b/gdb/testsuite/gdb.base/coredump-filter.exp @@ -62,7 +62,7 @@ proc do_load_and_test_core { core var working_var working_value dump_excluded } # Access the memory the addresses point to. if { $dump_excluded == 0 } { - gdb_test "print/x *(char *) $coredump_var_addr($var)" "\(${::valnum_re} = \)?" \ + gdb_test "print/x *(char *) $coredump_var_addr($var)" "(Cannot access memory at address $hex|${::valnum_re} = )" \ "printing $var when core is loaded (should not work)" gdb_test "print/x *(char *) $coredump_var_addr($working_var)" " = $working_value.*" \ "print/x *$working_var ( = $working_value)" diff --git a/gdb/testsuite/gdb.base/corefile.exp b/gdb/testsuite/gdb.base/corefile.exp index 957bccf43a40..f6a0a7a1ecad 100644 --- a/gdb/testsuite/gdb.base/corefile.exp +++ b/gdb/testsuite/gdb.base/corefile.exp @@ -229,7 +229,7 @@ gdb_test "x/8bd buf2" \ "accessing mmapped data in core file with coremmap.data removed" gdb_test "x/8bd buf2ro" \ - "$hex\[^:\]*:\\s+Cannot access memory at address $hex" \ + "$hex\[^:\]*:(\\s+){8}" \ "accessing read-only mmapped data in core file with coremmap.data removed" # Restore the coremmap.data file so later tests don't give warnings diff --git a/gdb/testsuite/gdb.debuginfod/corefile-mapped-file.exp b/gdb/testsuite/gdb.debuginfod/corefile-mapped-file.exp index 784762c2057d..b1934c6b7e4d 100644 --- a/gdb/testsuite/gdb.debuginfod/corefile-mapped-file.exp +++ b/gdb/testsuite/gdb.debuginfod/corefile-mapped-file.exp @@ -144,7 +144,7 @@ proc read_ptr_value { } { -re -wrap "^${::hex}(?:\\s+<\[^>\]+>)?:\\s+($::hex)" { set value $expect_out(1,string) } - -re -wrap "^${::hex}(?:\\s+<\[^>\]+>)?:\\s+Cannot access memory at address ${::hex}" { + -re -wrap "^${::hex}(?:\\s+<\[^>\]+>)?:\\s+" { set value "unavailable" } } base-commit: dd9a411627a249b7b3dfb4ad879c62d862dc93e3 -- 2.53.0