[PATCH] gdb questions: fallback on maps still relevant today ?

[PATCH] gdb questions: fallback on maps still relevant today ?

[Matthieu Longo]

I am wondering whether the fallback on maps when reading smaps is still
relevant nowadays. /proc/$PID/smaps has been around since 2005. I doubt
that anyone using an older Linux kernel version out there would use the
latest version of GDB.
I propose to remove this fallback logic in linux_find_memory_regions_full.

Additionnally, reading from smaps file is tested against NULL. Why ?
Is there such a valid case where the result of target_fileio_read_stralloc()
could be null, and at the same time, GDB is attached to a process, local
or remote via gdbserver, or while reading a coredump ?
In my understanding, all those cases ensures that the smaps file is always
present and so, I propose to replace this check with a gdb_assert instead.

Why do I care about the above ?
I would like to wrap the reading and parsing code in a class to avoid
the duplication of all the boiler plates in different places.
Please let me know your thoughts ?
---
 gdb/linux-tdep.c | 9 ++++++++-
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/gdb/linux-tdep.c b/gdb/linux-tdep.c
index 6af01fc0e26..2903e853890 100644
--- a/gdb/linux-tdep.c
+++ b/gdb/linux-tdep.c
@@ -1667,6 +1667,7 @@ linux_process_address_in_memtag_page (CORE_ADDR address)
   gdb::unique_xmalloc_ptr<char> data
     = target_fileio_read_stralloc (NULL, smaps_file.c_str ());
 
+  // Why would the data be suddenly unavailable ? Should this be an assert instead ?
   if (data == nullptr)
     return false;
 
@@ -1759,10 +1760,15 @@ linux_find_memory_regions_full (struct gdbarch *gdbarch,
 
   if (data == NULL)
     {
-      /* Older Linux kernels did not support /proc/PID/smaps.  */
+      /* Older Linux kernels did not support /proc/PID/smaps.
+	 /proc/<pid>/smaps was introduced in Linux 2.6.14, released on 27
+	 October 2005 (see proc_pid_smaps(5) — Linux manual page).
+	 Should we really care about this very very old version ?
+	 Does this fallback really make sense nowadays ?  */
       maps_filename = string_printf ("/proc/%d/maps", pid);
       data = target_fileio_read_stralloc (NULL, maps_filename.c_str ());
 
+      // Should this check be an assert instead ?
       if (data == nullptr)
 	return false;
     }
@@ -3183,6 +3189,7 @@ linux_address_in_shadow_stack_mem_range
   gdb::unique_xmalloc_ptr<char> data
     = target_fileio_read_stralloc (nullptr, smaps_file.c_str ());
 
+  // Should this check be an assert instead ?
   if (data == nullptr)
     return false;
 
-- 
2.55.0

Re: [PATCH] gdb questions: fallback on maps still relevant today ?

[Luis]

Hi,

On 01/07/2026 13:17, Matthieu Longo wrote:
> I am wondering whether the fallback on maps when reading smaps is still
> relevant nowadays. /proc/$PID/smaps has been around since 2005. I doubt
> that anyone using an older Linux kernel version out there would use the
> latest version of GDB.
> I propose to remove this fallback logic in linux_find_memory_regions_full.

That´d be fine by me. We might want to do the deprecation dance and then 
drop from a future release.

> 
> Additionnally, reading from smaps file is tested against NULL. Why ?
> Is there such a valid case where the result of target_fileio_read_stralloc()
> could be null, and at the same time, GDB is attached to a process, local
> or remote via gdbserver, or while reading a coredump ?
> In my understanding, all those cases ensures that the smaps file is always
> present and so, I propose to replace this check with a gdb_assert instead.

There are error cases. And this file isn´t something static on disk but 
rather a dynamically-created file on request. Due to that, bad things 
can happen and a read may fail.

We don´t want to assert on a temporary hiccup as it will completely kill 
gdb during a debug session. If this error ever happens the user gets a 
warning or error message and can take action. That isn´t the case with 
assertions.

> 
> Why do I care about the above ?
> I would like to wrap the reading and parsing code in a class to avoid
> the duplication of all the boiler plates in different places.

Can´t you accomplish that already regardless of whether reading smaps 
fails or not?

> Please let me know your thoughts ?

I'm all for tidying things up. And I'm OK with dropping the fallback too.

Re: [PATCH] gdb questions: fallback on maps still relevant today ?

[Matthieu Longo]

On 01/07/2026 13:33, Luis wrote:
> Hi,
> 
> On 01/07/2026 13:17, Matthieu Longo wrote:
>> I am wondering whether the fallback on maps when reading smaps is still
>> relevant nowadays. /proc/$PID/smaps has been around since 2005. I doubt
>> that anyone using an older Linux kernel version out there would use the
>> latest version of GDB.
>> I propose to remove this fallback logic in linux_find_memory_regions_full.
> 
> That´d be fine by me. We might want to do the deprecation dance and then drop from a future release.
> 

What do you mean by "deprecation dance" ?
What would the steps be to get rid of this fallback ?
>> Additionnally, reading from smaps file is tested against NULL. Why ?
>> Is there such a valid case where the result of target_fileio_read_stralloc()
>> could be null, and at the same time, GDB is attached to a process, local
>> or remote via gdbserver, or while reading a coredump ?
>> In my understanding, all those cases ensures that the smaps file is always
>> present and so, I propose to replace this check with a gdb_assert instead.
> 
> There are error cases. And this file isn´t something static on disk but rather a dynamically-created
> file on request. Due to that, bad things can happen and a read may fail.
> 
> We don´t want to assert on a temporary hiccup as it will completely kill gdb during a debug session.
> If this error ever happens the user gets a warning or error message and can take action. That isn´t
> the case with assertions.
> 

Ok

>>
>> Why do I care about the above ?
>> I would like to wrap the reading and parsing code in a class to avoid
>> the duplication of all the boiler plates in different places.
> 
> Can´t you accomplish that already regardless of whether reading smaps fails or not?
>

I can. I was wondering whether it was possible to tidy things up before adding wrappers.

Matthieu

Re: [PATCH] gdb questions: fallback on maps still relevant today ?

[Tom Tromey]

>> That´d be fine by me. We might want to do the deprecation dance and
>> then drop from a future release.

Matthieu> What do you mean by "deprecation dance" ?
Matthieu> What would the steps be to get rid of this fallback ?

A kind of normal thing to do would be to warn users that this is going
to happen, and then make the change in release N+1.

Another approach though might be to just remove the code, since it's so
very old, and then have a fallback that warns if smaps is not found but
maps is.

gdb frequently struggles with removing dead code.  We're not always sure
it's truly dead, and some people out there run weird and/or antique
setups.

Tom