gdb: only use /proc/PID/exe for local f/s with no sysroot

This commit works around a problem introduced by commit:

  commit e58beedf2c8a1e0c78e0f57aeab3934de9416bfc
  Date:   Tue Jan 23 16:00:59 2024 +0000

      gdb: attach to a process when the executable has been deleted

The above commit extended GDB for Linux, so that, of the executable
for a process had been deleted, GDB would instead try to use
/proc/PID/exe as the executable.

This worked by updating linux_proc_pid_to_exec_file to introduce the
/proc/PID/exe fallback.  However, the result of
linux_proc_pid_to_exec_file is then passed to exec_file_find to
actually find the executable, and exec_file_find, will take into
account the sysroot.  In addition, if GDB is attaching to a process in
a different MNT and/or PID namespace then the executable lookup is
done within that namespace.

This all means two things:

  1. Just because linux_proc_pid_to_exec_file cannot see the
     executable doesn't mean that GDB is actually going to fail to
     find the executable, and

  2. returning /proc/PID/exe isn't useful if we know GDB is then going
     to look for this within a sysroot, or within some other
     namespace (where PIDs might be different).

There was an initial attempt to fix this issue here:

  https://inbox.sourceware.org/gdb-patches/20250511141517.2455092-4-kilger@sec.in.tum.de/

This proposal addresses the issue in PR gdb/32955, which is all about
the namespace side of the problem.  The fix in this original proposal
is to check the MNT namespace inside linux_proc_pid_to_exec_file, and
for the namespace problem this is fine.  But we should also consider
the sysroot problem.

And for the sysroot problem, the fix cannot fully live inside
linux_proc_pid_to_exec_file, as linux_proc_pid_to_exec_file is shared
between GDB and gdbserver, and gdbserver has no sysroot.

And so, I propose a slightly bigger change.

Now, linux_proc_pid_to_exec_file takes a flag which indicates if
GDB (or gdbserver) will look for the inferior executable in the
local file system, where local means the same file system as GDB (or
gdbserver) is running in.

This local file system check is true if:

  1. The MNT namespace of the inferior is the same as for GDB, and

  2. for GDB only, the sysroot must either be empty, or 'target:'.

If the local file system check is false then GDB (or gdbserver) is
going to look elsewhere for the inferior executable, and so, falling
back to /proc/PID/exe should not be done, as GDB will end up looking
for this file in the sysroot, or within the alternative MNT
namespace (which in also likely to be a different PID namespace).

Now this is all a bit of a shame really.  It would be nice if
linux_proc_pid_to_exec_file could return /proc/PID/exe in such a way
that exec_file_find would know that the file should NOT be looked for
in the sysroot, or in the alternative namespace.  But fixing that
problem would be a much bigger change, so for now lets just disable
the /proc/PID/exe fallback for cases where it might not work.

For testing, the sysroot case is now tested.

I don't believe we have any alternative namespace testing.  It would
certainly be interesting to add some, but I'm not proposing any with
this patch, so the code for checking the MNT namespace has been tested
manually by me, but isn't covered by a new test I'm adding here.

Author of the original fix is listed as co-author here.  Credit for
identifying the original problem, and proposing a solution belongs to
them.

Co-Authored-By: Fabian Kilger <kilger@sec.in.tum.de>
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32955

0 files changed, 0 insertions, 0 deletions