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

[Eli Zaretskii <eliz@gnu.org>]

> 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".

Thanks.