From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id 33vUEtjspWlJMhEAWB0awg (envelope-from ) for ; Mon, 02 Mar 2026 15:02:32 -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=QPwXydG+; dkim-atps=neutral Received: by simark.ca (Postfix, from userid 112) id 36BA61E089; Mon, 02 Mar 2026 15:02:32 -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 71F641E089 for ; Mon, 02 Mar 2026 15:02:31 -0500 (EST) Received: from vm01.sourceware.org (localhost [127.0.0.1]) by sourceware.org (Postfix) with ESMTP id F00534BA23F4 for ; Mon, 2 Mar 2026 20:02:30 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org F00534BA23F4 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=QPwXydG+ Received: from smtp.polymtl.ca (smtp.polymtl.ca [132.207.4.11]) by sourceware.org (Postfix) with ESMTPS id 12FF84BA2E1D for ; Mon, 2 Mar 2026 20:02:05 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 12FF84BA2E1D 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 12FF84BA2E1D 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=1772481725; cv=none; b=ZnO8DIKjglbOfdIhyEAJbdLAQhbmpqT44wWK9RvdXg2DGFheQ2BUchVMylw9A7X4LCBHs264EF9Y46Gra3eXogWDrPO3Ii4spE+3kukctC2jC4Z+R5FzVbhMsYHnTJhECApH4FoXoDyjyZ5TdKji/KsoxUamatfqwlN6TY5k7To= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1772481725; c=relaxed/simple; bh=Y+8MaoGCH2nHyYqOpIPsMEfRRmETSj2rWbfVK6jVB4A=; h=DKIM-Signature:Message-ID:Date:MIME-Version:Subject:To:From; b=SgdBz+LtZnBwzppZrs+a2Zq8NJz/cRFCEhYxnjXHSh1LmO6PArtkTLm6l7zX4RSNwQDaDhMnpz9epw47/Qu61I+SZ6sWYWLID0bgpdFK0vCby4ZG9WL5czVmQMAC6wB0dtluXFDlD+/QBzWL0BIdbTLsb909cXATGGgk4ljJSq4= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 12FF84BA2E1D 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 622K1mJv154887 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 2 Mar 2026 15:01:53 -0500 DKIM-Filter: OpenDKIM Filter v2.11.0 smtp.polymtl.ca 622K1mJv154887 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=polymtl.ca; s=oct2025; t=1772481714; bh=34gzR3dPvowg6WGc2MU3lw42Mdezy/tN8opoNq4LK00=; h=Date:Subject:To:Cc:From:In-Reply-To:From; b=QPwXydG+yJtjkQ/xbNWagmM1+yBXaAMpQIKMhZYj49HWp06KFOyXb40sxJa9OktwL 7uCwUtYGsm2dDumxgeCRl2lG5Uj3+p5tQXFFSxk33mHtihEfN586SDE65vSYWISPBp Y70D2gVSWdWAAE4jEpukqvqf2dYR6MDpRG8Y4dpK/My/ko9LIsT1nsrtpnpsUfS+aO LaxN2hUKY9+uzRjQ13MGerzqeb6CYQBGzOmRz39EZQM5HY3IQj7CgAdieEeJ6sx1Zk yHJpPaVUt9i3KE3K5BNFfp0DHPTCpRCZARrVUAa3nNkwV2RdtIO+VNldRNIRF0/MlD Ojn1/7pCiExCw== Received: by simark.ca (Postfix) id 8D35D1E089; Mon, 02 Mar 2026 15:01:47 -0500 (EST) Message-ID: <7fa9be38-b8b1-4832-9e22-563d1795336d@polymtl.ca> Date: Mon, 2 Mar 2026 15:01:47 -0500 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2] gdb/corelow: mark bytes unavailable when reading from unavailable mapping To: "Aktemur, Tankut Baris" , 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: 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 20:01:49 +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 10:49, Aktemur, Tankut Baris wrote: > On Monday, March 2, 2026 2:01 PM, 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? > > Does the patch enable partial printing of structs? > > Suppose there is a struct with a field 'x' whose value is available (e.g. its a > constant, or was promoted to a register, etc.) and another field 'y' that is > located in unavailable memory. Would we get something like > > $1 = {x = 42, y = } > > instead of a complete "Cannot access memory" error? If that's the case, > it could be considered an improvement, even though it does not explain > why the value is unavailable. I can't test it right now (I'm not really working right now), but yes I assume that's what it would do. The unavailable status has historically been more used for the tracing stuff, so there might be examples in the gdb.trace testsuite directory. It should work the same with core files. But I also don't know how the struct value printing code behaves when encountering an error, whether it prints an error message and carries on to the next field or if it aborts completely. Simon