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

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

[Simon Marchi]

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>

Note that the same concept exists on Linux with the minicoredumper
project [1].  We could adjust the core target to act the same way when
dealing with minicoredumps.

[1] https://www.linutronix.de/minicoredumper/

Change-Id: I4df82ba4116e87545691facec0cb662c4b2b7797
---
 gdb/corelow.c                       | 3 ++-
 gdb/testsuite/gdb.base/corefile.exp | 2 +-
 2 files changed, 3 insertions(+), 2 deletions(-)

diff --git a/gdb/corelow.c b/gdb/corelow.c
index a28a707c293a..57d05504fa3c 100644
--- a/gdb/corelow.c
+++ b/gdb/corelow.c
@@ -1470,7 +1470,8 @@ core_target::xfer_partial (enum target_object object, const char *annex,
 		if (xfer_status == TARGET_XFER_OK)
 		  return TARGET_XFER_OK;
 
-		return TARGET_XFER_E_IO;
+		*xfered_len = len;
+		return TARGET_XFER_UNAVAILABLE;
 	      }
 	  }
 
diff --git a/gdb/testsuite/gdb.base/corefile.exp b/gdb/testsuite/gdb.base/corefile.exp
index 957bccf43a40..f6a0a7a1ecad 100644
--- a/gdb/testsuite/gdb.base/corefile.exp
+++ b/gdb/testsuite/gdb.base/corefile.exp
@@ -229,7 +229,7 @@ gdb_test "x/8bd buf2" \
     "accessing mmapped data in core file with coremmap.data removed"
 
 gdb_test "x/8bd buf2ro" \
-    "$hex\[^:\]*:\\s+Cannot access memory at address $hex" \
+    "$hex\[^:\]*:(\\s+<unavailable>){8}" \
     "accessing read-only mmapped data in core file with coremmap.data removed"
 
 # Restore the coremmap.data file so later tests don't give warnings

base-commit: d7f532cb3a46527c56963a2c713e29cee4f64eee
-- 
2.53.0

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

[simon.marchi]

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>

Note that the same concept exists on Linux with the minicoredumper
project [1].  We could adjust the core target to act the same way when
dealing with minicoredumps.

[1] https://www.linutronix.de/minicoredumper/

Change-Id: I4df82ba4116e87545691facec0cb662c4b2b7797
---
 gdb/corelow.c                                         | 3 ++-
 gdb/testsuite/gdb.base/coredump-filter.exp            | 2 +-
 gdb/testsuite/gdb.base/corefile.exp                   | 2 +-
 gdb/testsuite/gdb.debuginfod/corefile-mapped-file.exp | 2 +-
 4 files changed, 5 insertions(+), 4 deletions(-)

diff --git a/gdb/corelow.c b/gdb/corelow.c
index a28a707c293a..57d05504fa3c 100644
--- a/gdb/corelow.c
+++ b/gdb/corelow.c
@@ -1470,7 +1470,8 @@ core_target::xfer_partial (enum target_object object, const char *annex,
 		if (xfer_status == TARGET_XFER_OK)
 		  return TARGET_XFER_OK;
 
-		return TARGET_XFER_E_IO;
+		*xfered_len = len;
+		return TARGET_XFER_UNAVAILABLE;
 	      }
 	  }
 
diff --git a/gdb/testsuite/gdb.base/coredump-filter.exp b/gdb/testsuite/gdb.base/coredump-filter.exp
index c35a0334ff33..e2ce86d48e8a 100644
--- a/gdb/testsuite/gdb.base/coredump-filter.exp
+++ b/gdb/testsuite/gdb.base/coredump-filter.exp
@@ -62,7 +62,7 @@ proc do_load_and_test_core { core var working_var working_value dump_excluded }
 
     # Access the memory the addresses point to.
     if { $dump_excluded == 0 } {
-	gdb_test "print/x *(char *) $coredump_var_addr($var)" "\(${::valnum_re} = <error: \)?Cannot access memory at address $hex\(>\)?" \
+	gdb_test "print/x *(char *) $coredump_var_addr($var)" "(Cannot access memory at address $hex|${::valnum_re} = <unavailable>)" \
 	    "printing $var when core is loaded (should not work)"
 	gdb_test "print/x *(char *) $coredump_var_addr($working_var)" " = $working_value.*" \
 	    "print/x *$working_var ( = $working_value)"
diff --git a/gdb/testsuite/gdb.base/corefile.exp b/gdb/testsuite/gdb.base/corefile.exp
index 957bccf43a40..f6a0a7a1ecad 100644
--- a/gdb/testsuite/gdb.base/corefile.exp
+++ b/gdb/testsuite/gdb.base/corefile.exp
@@ -229,7 +229,7 @@ gdb_test "x/8bd buf2" \
     "accessing mmapped data in core file with coremmap.data removed"
 
 gdb_test "x/8bd buf2ro" \
-    "$hex\[^:\]*:\\s+Cannot access memory at address $hex" \
+    "$hex\[^:\]*:(\\s+<unavailable>){8}" \
     "accessing read-only mmapped data in core file with coremmap.data removed"
 
 # Restore the coremmap.data file so later tests don't give warnings
diff --git a/gdb/testsuite/gdb.debuginfod/corefile-mapped-file.exp b/gdb/testsuite/gdb.debuginfod/corefile-mapped-file.exp
index 784762c2057d..b1934c6b7e4d 100644
--- a/gdb/testsuite/gdb.debuginfod/corefile-mapped-file.exp
+++ b/gdb/testsuite/gdb.debuginfod/corefile-mapped-file.exp
@@ -144,7 +144,7 @@ proc read_ptr_value { } {
 	-re -wrap "^${::hex}(?:\\s+<\[^>\]+>)?:\\s+($::hex)" {
 	    set value $expect_out(1,string)
 	}
-	-re -wrap "^${::hex}(?:\\s+<\[^>\]+>)?:\\s+Cannot access memory at address ${::hex}" {
+	-re -wrap "^${::hex}(?:\\s+<\[^>\]+>)?:\\s+<unavailable>" {
 	    set value "unavailable"
 	}
     }

base-commit: dd9a411627a249b7b3dfb4ad879c62d862dc93e3
-- 
2.53.0

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

[Eli Zaretskii]

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

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

[Aktemur, Tankut Baris]

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

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

[Simon Marchi]

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

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

[Simon Marchi]

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

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

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

[Tom Tromey]

>>>>> "Simon" == simon marchi <simon.marchi@polymtl.ca> writes:

Simon> The main motivation for this change is to nicely support "lightweight"
Simon> core files on ROCm (more on this below), but I think that the change
Simon> also makes sense for regular core files.

FWIW this all makes sense to me.

Simon> diff --git a/gdb/corelow.c b/gdb/corelow.c
Simon> index a28a707c293a..57d05504fa3c 100644
Simon> --- a/gdb/corelow.c
Simon> +++ b/gdb/corelow.c
Simon> @@ -1470,7 +1470,8 @@ core_target::xfer_partial (enum target_object object, const char *annex,
Simon>  		if (xfer_status == TARGET_XFER_OK)
Simon>  		  return TARGET_XFER_OK;
 
Simon> -		return TARGET_XFER_E_IO;
Simon> +		*xfered_len = len;
Simon> +		return TARGET_XFER_UNAVAILABLE;
Simon>  	      }
Simon>  	  }
 
Just before this is a comment ending with

	   If that fails, but the access is within an unavailable region,
	   then the access itself should fail.  */

but perhaps this could be reworded to not say "fail" but something about
unavailability.

Though honestly this is kind of a nit since the code speaks for itself.

Anyway I think this is good.
Approved-By: Tom Tromey <tom@tromey.com>

Tom

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

[Tom Tromey]

>>>>> "Eli" == Eli Zaretskii <eliz@gnu.org> writes:

>> (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>

Eli> I wonder whether <unavailable> is really better here.  You don't
Eli> explain why "cannot access memory" needs improvement -- can you tell
Eli> what is wrong with that?

Eli> If anything, I'd say something more specific, like "could not be read
Eli> from core file".

There is a difference between "unavailable" (nobody saved the data) and
"failed" (the pointer is bad, you have some kind of bug).  Pointing this
out when possible seems like an improvement to me.

I agree that the wording could be more precise in some cases.
At the same time I feel that's a separate issue from this patch.

thanks,
Tom

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

[Simon Marchi]

On 3/4/26 11:36 AM, Tom Tromey wrote:
>>>>>> "Simon" == simon marchi <simon.marchi@polymtl.ca> writes:
> 
> Simon> The main motivation for this change is to nicely support "lightweight"
> Simon> core files on ROCm (more on this below), but I think that the change
> Simon> also makes sense for regular core files.
> 
> FWIW this all makes sense to me.
> 
> Simon> diff --git a/gdb/corelow.c b/gdb/corelow.c
> Simon> index a28a707c293a..57d05504fa3c 100644
> Simon> --- a/gdb/corelow.c
> Simon> +++ b/gdb/corelow.c
> Simon> @@ -1470,7 +1470,8 @@ core_target::xfer_partial (enum target_object object, const char *annex,
> Simon>  		if (xfer_status == TARGET_XFER_OK)
> Simon>  		  return TARGET_XFER_OK;
>  
> Simon> -		return TARGET_XFER_E_IO;
> Simon> +		*xfered_len = len;
> Simon> +		return TARGET_XFER_UNAVAILABLE;
> Simon>  	      }
> Simon>  	  }
>  
> Just before this is a comment ending with
> 
> 	   If that fails, but the access is within an unavailable region,
> 	   then the access itself should fail.  */
> 
> but perhaps this could be reworded to not say "fail" but something about
> unavailability.
> 
> Though honestly this is kind of a nit since the code speaks for itself.

It's an easy enough fix and it's good to be precise.  Changed it to:

	   If that fails, but the access is within an unavailable region,
	   then report the bytes as unavailable.  */

> Anyway I think this is good.
> Approved-By: Tom Tromey <tom@tromey.com>

Thanks, pushed.

Simon