RE: [PATCH v2] gdb/corelow: mark bytes unavailable when reading from unavailable mapping

["Aktemur, Tankut Baris" <tankut.baris.aktemur@intel.com>]

On Monday, March 2, 2026 2:01 PM, Eli Zaretskii wrote:
> > From: simon.marchi@polymtl.ca
> > Cc: Simon Marchi <simon.marchi@efficios.com>
> > Date: Sun,  1 Mar 2026 22:23:05 -0500
> >
> > From: Simon Marchi <simon.marchi@efficios.com>
> >
> > 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: <unavailable>   <unavailable>   <unavailable>   <unavailable>
> <unavailable>   <unavailable>   <unavailable>   <unavailable>
> >
> > 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 = <unavailable>
> 
> I wonder whether <unavailable> 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 = <unavailable>}

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.

-Baris


Intel Deutschland GmbH
Registered Address: Dornacher Straße 1, 85622 Feldkirchen, Germany
Tel: +49 89 991 430, www.intel.de
Managing Directors: Harry Demas, Jeffrey Schneiderman, Yin Chong Sorrell
Chairperson of the Supervisory Board: Nicole Lau
Registered Seat: Munich
Commercial Register: Amtsgericht München HRB 186928