Re: [PATCH] gdb/linux-nat: Fix mem access ptrace fallback (PR threads/31579)

[Hannes Domani <ssbssa@yahoo.de>]

 Am Donnerstag, 11. April 2024 um 13:40:25 MESZ hat Pedro Alves <pedro@palves.net> Folgendes geschrieben:

> Old RHEL systems have a kernel that does not support writing memory
> via /proc/pid/mem.  On such systems, we fallback to accessing memory
> via ptrace.  That has a few downsides described in the "Accessing
> inferior memory" section at the top of linux-nat.c.
>
> The target_xfer interface for memory access uses inferior_ptid as
> sideband argument to indicate which process to access.  Memory access
> is process-wide, it is not thread-specific, so inferior_ptid is
> sometimes pointed at a process-wide ptid_t for the memory access
> (i.e., a ptid that looks like {pid, 0, 0}).  That is the case for any
> code that uses scoped_restore_current_inferior_for_memory, for
> example.
>
> That is what causes the issue described in PR 31579, where thread_db
> calls into the debugger to read memory, which reaches our
> ps_xfer_memory function, which does:
>
>   static ps_err_e
>   ps_xfer_memory (const struct ps_prochandle *ph, psaddr_t addr,
>           gdb_byte *buf, size_t len, int write)
>   {
>     scoped_restore_current_inferior_for_memory save_inferior (ph->thread->inf);
>
>     ...
>       ret = target_read_memory (core_addr, buf, len);
>     ...
>   }
>
> If linux_nat_target::xfer_partial falls back to inf_ptrace_target with
> a pid-ptid, then the ptrace code will do the ptrace call targeting
> pid, the leader LWP.  That may fail with ESRCH if the leader is
> currently running, or zombie.  That is the case in the scenario in
> question, because thread_db is consulted for an event of a non-leader
> thread, before we've stopped the whole process.
>
> Fix this by having the ptrace fallback code try to find a stopped LWP
> to use with ptrace.
>
> I chose to handle this in the linux-nat target instead of in common
> code because (global) memory is a process-wide property, and this
> avoids having to teach all the code paths that use
> scoped_restore_current_inferior_for_memory to find some stopped thread
> to access memory through, which is a ptrace quirk.  That is
> effectively what we used to do before we started relying on writable
> /proc/pid/mem.  I'd rather not go back there.
>
> To trigger this on modern kernels you have to hack linux-nat.c to
> force the ptrace fallback code, like so:
>
> --- a/gdb/linux-nat.c
> +++ b/gdb/linux-nat.c
> @@ -3921,7 +3921,7 @@ linux_nat_target::xfer_partial (enum target_object object,
>       poke would incorrectly write memory to the post-exec address
>       space, while the core was trying to write to the pre-exec
>       address space.  */
> -      if (proc_mem_file_is_writable ())
> +      if (0 && proc_mem_file_is_writable ())
>
> With that hack, I was able to confirm that the fix fixes hundreds of
> testsuite failures.  Compared to a test run with pristine master, the
> hack above + this commit's fix shows that some non-stop-related tests
> fail, but that is expected, because those are tests that need to write
> memory while the program is running.  (I made no effort to temporarily
> pause an lwp if no ptrace-stopped lwp is found.)

I can confirm that this fixes the problem for me, thanks.

Tested-By: Hannes Domani <ssbssa@yahoo.de>