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

[Simon Marchi <simon.marchi@polymtl.ca>]

On 2026-03-02 08:00, 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?
> 
> 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