From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id Fl2QNQfrpWlmMBEAWB0awg (envelope-from ) for ; Mon, 02 Mar 2026 14:54:47 -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=D47SvOQM; dkim-atps=neutral Received: by simark.ca (Postfix, from userid 112) id BE07B1E0DD; Mon, 02 Mar 2026 14:54:47 -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 1E5461E089 for ; Mon, 02 Mar 2026 14:54:46 -0500 (EST) Received: from vm01.sourceware.org (localhost [127.0.0.1]) by sourceware.org (Postfix) with ESMTP id 999804BA23E0 for ; Mon, 2 Mar 2026 19:54:44 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 999804BA23E0 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=D47SvOQM Received: from smtp.polymtl.ca (smtp.polymtl.ca [132.207.4.11]) by sourceware.org (Postfix) with ESMTPS id BC22A4BA23C6 for ; Mon, 2 Mar 2026 19:54:17 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org BC22A4BA23C6 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 BC22A4BA23C6 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=1772481257; cv=none; b=cBuUjbtikfHdRNmfU8ysCbrFfJHMRPnJCEs7evI6mg9Q/9fQ85ex7wh2rDlqNSiC4UmXZLa/w3jmkRNxAP7tQ4FrLkIbgO3WH440U7nrsevdrT7GR7r89wzBfg9HgydCdEeBE57cpuTTjIrYT0E88PapsmjkvwukwHRIk682Epk= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1772481257; c=relaxed/simple; bh=p3oG0Je1eQj3Wmu6GZaqT15nrCSi1VFSiFV2ni0bjDI=; h=DKIM-Signature:Message-ID:Date:MIME-Version:Subject:To:From; b=nAgtarNuk9t5y5GZXum8Hm+eEzMIOGyQ0IJNFKnAMqAY9JCRiGyTricgJTRhpnGgpI80x1L59AuLygDWQGSt19vu3SuRXdd38FHEDS0g1iWp09u3FemEISIfk14/+D5YH57a1ghy2lxnxv2QTgsO9bf++h2qUXYA+OCTcWyt6sg= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org BC22A4BA23C6 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 622Js4EM152332 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 2 Mar 2026 14:54:09 -0500 DKIM-Filter: OpenDKIM Filter v2.11.0 smtp.polymtl.ca 622Js4EM152332 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=polymtl.ca; s=oct2025; t=1772481249; bh=M+0st4vQ0ihT2Mlm+AC+gXBlq+q/4xkpDi4RIw9pBw0=; h=Date:Subject:To:Cc:From:In-Reply-To:From; b=D47SvOQMsQmeMDrK9B7sUaceje9lYHsu5Tcz2Q6nwcS1VEgb+7uVE6m6ryXOux66I eMn8RXFMd0mGr9wqHyhdHCgNHdz/f2roKxk9U22vNMrsz0AzH3MBRNVAIlBHK3GF0G uaQheK0QFS5aTjiV1d9N+Sc7fAf/lIVtjSDCK/RD/jbUfTtSvzEaE9Jb53U754J4ZN A5nwhD/in+tcu1OLfIXD9dd2dXe80rTInkbK8v5K0WuVshusiIhJAlFtG8rSaUp0hk TYNyU397Q4aPv/GOShTm+5xIo68YfJSNUHbywAzvXjHPNJexgf2OVzlvFGLGbe/aqJ +oQgjkuBdXCSQ== Received: by simark.ca (Postfix) id 3C7E41E089; Mon, 02 Mar 2026 14:54:03 -0500 (EST) Message-ID: Date: Mon, 2 Mar 2026 14:54:02 -0500 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2] gdb/corelow: mark bytes unavailable when reading from unavailable mapping To: Eli Zaretskii Cc: gdb-patches@sourceware.org References: <20260228022059.117785-1-simon.marchi@efficios.com> <20260302032333.2287923-1-simon.marchi@polymtl.ca> <864imyz8r4.fsf@gnu.org> Content-Language: en-US From: Simon Marchi In-Reply-To: <864imyz8r4.fsf@gnu.org> 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 19:54:04 +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 On 2026-03-02 08:00, Eli Zaretskii wrote: >> From: simon.marchi@polymtl.ca >> Cc: Simon Marchi >> Date: Sun, 1 Mar 2026 22:23:05 -0500 >> >> 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 = > > I wonder whether is really better here. You don't > explain why "cannot access memory" needs improvement -- can you tell > what is wrong with that? > > If anything, I'd say something more specific, like "could not be read > from core file". This is the intended meaning of "unavailable": https://gitlab.com/gnutools/binutils-gdb/-/blob/1e6ad73d0827a246023ba17ca61b35649e3982bb/gdb/value.h#L41-53 Simon