Re: why ptrace read failed to read debugging process memory?

[Pedro Alves <pedro@palves.net>]

On 2022-03-10 06:40, 周春明(日月) via Gdb-patches wrote:
> Hi GDB maintainers,
> I tried update our gdb10 to gdb12, but I found new gdb seems cannot pread debugging process memory.
> 
> 3897 linux_proc_xfer_memory_partial (gdb_byte *readbuf, const gdb_byte *writebuf,
> 3898  ULONGEST offset, LONGEST len,
> 3899  ULONGEST *xfered_len)
> 3900 {
> 3901  ssize_t ret;
> 3902  auto iter = proc_mem_file_map.find (inferior_ptid.pid ());
> 3903  if (iter == proc_mem_file_map.end ())
> 3904  return TARGET_XFER_EOF;
> 3905
> 3906  int fd = iter->second.fd ();
> 3907
> 3908  gdb_assert (fd != -1);
> 3909
> 3910  /* Use pread64/pwrite64 if available, since they save a syscall and can
> 3911   handle 64-bit offsets even on 32-bit platforms (for instance, SPARC
> 3912   debugging a SPARC64 application). */
> 3913 #ifdef HAVE_PREAD64
> 3914  ret = (readbuf ? pread64 (fd, readbuf, len, offset)
> 3915   : pwrite64 (fd, writebuf, len, offset));
> 3916 #else
> 3917  ret = lseek (fd, offset, SEEK_SET);
> 3918  if (ret != -1)
> 3919  ret = (readbuf ? read (fd, readbuf, len)
> 3920   : write (fd, writebuf, len));
> 3921 #endif
> 3922
> 3923  if (ret == -1)
> 3924  {
> 3925  printf ("accessing fd %d for pid %d failed: %s (%d)\n",         ================> here always returns -EIO (5) errno.
> 3926  fd, inferior_ptid.pid (),
> 3927  safe_strerror (errno), errno);
> 3928  return TARGET_XFER_EOF;
> 3929  }
> 
> any configure I missed in new GDB12? or new ptrace way needed?

In prior GDB versions, GDB would always use PTRACE_PEEKTEXT/PTRACE_POKETEXT for memory accesses (< 3 * sizeof(long)).
If the access was larger, then it would first try /proc/pid/mem, and if that failed, would would try with
PTRACE_PEEKTEXT/PTRACE_POKETEXT.  GDB 12 always goes straight to /proc/pid/mem, and the PTRACE_PEEKTEXT/PTRACE_POKETEXT
fallback was removed.  This was done because /proc/pid/mem lets you access memory even if the ptracee is not stopped,
while ptrace fails in that case.

I'd debug gdb10, and see how does linux_nat_target::xfer_partial manage to read memory there, see if the /proc access
always fails there.

If that is the case, then the next question would be, why does it fail in the first place?