From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id aZpuByOKpWlwtBAAWB0awg (envelope-from ) for ; Mon, 02 Mar 2026 08:01:23 -0500 Authentication-Results: simark.ca; dkim=pass (2048-bit key; unprotected) header.d=gnu.org header.i=@gnu.org header.a=rsa-sha256 header.s=fencepost-gnu-org header.b=obbQ5j5A; dkim-atps=neutral Received: by simark.ca (Postfix, from userid 112) id 190591E089; Mon, 02 Mar 2026 08:01:23 -0500 (EST) X-Spam-Checker-Version: SpamAssassin 4.0.1 (2024-03-25) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-3.4 required=5.0 tests=ARC_SIGNED,ARC_VALID,BAYES_00, DKIMWL_WL_HIGH,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=unavailable 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 575321E089 for ; Mon, 02 Mar 2026 08:01:22 -0500 (EST) Received: from vm01.sourceware.org (localhost [127.0.0.1]) by sourceware.org (Postfix) with ESMTP id D0CD74BA23CD for ; Mon, 2 Mar 2026 13:01:21 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org D0CD74BA23CD Authentication-Results: sourceware.org; dkim=pass (2048-bit key, unprotected) header.d=gnu.org header.i=@gnu.org header.a=rsa-sha256 header.s=fencepost-gnu-org header.b=obbQ5j5A Received: from eggs.gnu.org (eggs.gnu.org [IPv6:2001:470:142:3::10]) by sourceware.org (Postfix) with ESMTPS id BBB5E4BA23C6 for ; Mon, 2 Mar 2026 13:00:35 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org BBB5E4BA23C6 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gnu.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gnu.org ARC-Filter: OpenARC Filter v1.0.0 sourceware.org BBB5E4BA23C6 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=2001:470:142:3::10 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1772456435; cv=none; b=CnSFRWC1fwFWtxbLG/4k7/GBlaeVsEtLRCTINvyCHRPMtyJvAznM9zPgvOudCo2wWvBz7a0+RADHUJ4KNlPp/hlkqVu8wdamlweNmDH1WngPEe4RdcNxi2iFR2FKOrGexY9j5lzk9f4l3RZ6sML7Ptz0zoDHAVxMw433+p4dDWk= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1772456435; c=relaxed/simple; bh=uBOXI79fhJMAYKCGKGSjZqjPQdCcYGWqaahiJSz+DQc=; h=DKIM-Signature:Date:Message-Id:From:To:Subject:MIME-version; b=bXsNMtsASQEWBzUgUFbd92Mus58scvl0uodZ83xygcHXkD/47qzafarXX62vNTzBSwqgdg8wzl75SWERcOgCI0Ol2UgwMKTYbwoaGdiBJ7oWwg5oe/IyU+0zHgGe9Lf8zr0EfaUGRTaOG6hcSrKI0SQxHaRmyRge+iK1UYwW9W4= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org BBB5E4BA23C6 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1vx2t0-0001tP-CR; Mon, 02 Mar 2026 08:00:34 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-version:References:Subject:In-Reply-To:To:From: Date; bh=YZKgRMFlvGyk8GbJrqMHEExIiMpVgVrx2p2klt6i8RY=; b=obbQ5j5AFKy5xHSLwVZI esIkrry2/zv/0sI0tYi8/7ArqJzlcbG5HlaCIyGt/pqwilTHxeGRDe6zguX9DN+de0ciBJh+GQ2z3 4KvxEvS8erSsP3vINPmid4GG1/ohKjnuY7c8GRhBBM5KoUH8rDSee6cUDh3Hr0XaAmsbi2lsfsNl8 7CxoRj81ScbXOxxgFopD8HZ/JKiWWPDu7uIZqsNfSpKBpdvhKJsVToBWTAL/i7++l88xWPa2B1Ank OyOpJV5Ph5muamQpX9n4lacoXq4gpnXEUdFd7SA1sR79EfHh7skBtLR8c5VAPuW3BWbGtbPtcEVKr vXHaYzCKE4ONOA==; Date: Mon, 02 Mar 2026 15:00:31 +0200 Message-Id: <864imyz8r4.fsf@gnu.org> From: Eli Zaretskii To: simon.marchi@polymtl.ca Cc: gdb-patches@sourceware.org In-Reply-To: <20260302032333.2287923-1-simon.marchi@polymtl.ca> Subject: Re: [PATCH v2] gdb/corelow: mark bytes unavailable when reading from unavailable mapping References: <20260228022059.117785-1-simon.marchi@efficios.com> <20260302032333.2287923-1-simon.marchi@polymtl.ca> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit 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@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". Thanks.