gdbserver/linux: Access memory even if threads are running
authorPedro Alves <pedro@palves.net>
Mon, 28 Mar 2022 17:35:34 +0000 (18:35 +0100)
committerPedro Alves <pedro@palves.net>
Thu, 14 Apr 2022 19:22:56 +0000 (20:22 +0100)
commit421490af33bfbfe8a8429f0e43fb3e9f8727476e
treed6a5ec2d36574605c40b8ef69bcc791ecc59056d
parent366e3746c572c2c78454761e62fa9181cba413ca
gdbserver/linux: Access memory even if threads are running

Similarly to how the native Linux target was changed
and subsequently reworked in these commits:

 05c06f318fd9 Linux: Access memory even if threads are running
 8a89ddbda2ec Avoid /proc/pid/mem races (PR 28065)

... teach GDBserver to access memory even when the current thread is
running, by always accessing memory via /proc/PID/mem.

The existing comment:

  /* Neither ptrace nor /proc/PID/mem allow accessing memory through a
     running LWP.  */

... is incorrect for /proc/PID/mem does allow that.

Actually, from GDB's perspective, GDBserver could already access
memory while threads were running, but at the expense of pausing all
threads for the duration of the memory access, via
prepare_to_access_memory.  This new implementation does not require
pausing any thread, thus
linux_process_target::prepare_to_access_memory /
linux_process_target::done_accessing_memory become nops.  A subsequent
patch will remove the whole prepare_to_access_memory infrastructure
completely.

The GDBserver linux-low.cc implementation is simpler than GDB's
linux-nat.c's, because GDBserver always adds the unfollowed vfork/fork
children to the process list immediately when the fork/vfork event is
seen out of ptrace.  I.e., there's no need to keep the file descriptor
stored on a side map, we can store it directly in the process
structure.

Change-Id: I0abfd782ceaa4ddce8d3e5f3e2dfc5928862ef61
gdbserver/linux-low.cc
gdbserver/linux-low.h