why ptrace read failed to read debugging process memory?

why ptrace read failed to read debugging process memory?

[周春明(日月)]

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?

Thanks very much,
-David

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

[Pedro Alves]

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?

回复：why ptrace read failed to read debugging process memory?

[周春明(日月)]

------------------------------------------------------------------
发件人：Pedro Alves <pedro@palves.net>
发送时间：2022年3月10日(星期四) 18:05
收件人：周春明(日月) <riyue.zcm@alibaba-inc.com>; Simon Marchi <simon.marchi@polymtl.ca>; Gdb-patches <gdb-patches-bounces+riyue.zcm=alibaba-inc.com@sourceware.org>; gdb-patches <gdb-patches@sourceware.org>
抄　送：Louis-He <1726110778@qq.com>; Dominique Quatravaux <dominique.quatravaux@epfl.ch>; Sam Warner <samuel.r.warner@me.com>
主　题：Re: why ptrace read failed to read debugging process memory?

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.

[David] Yeah, I did that today, the /proc access in gdb10 is successful.
I found the memaddr passed is different betwwen gdb12 and gdb10, it's  0x7fffd9000058 from bp_tgt->placed_address in gdb10, while 
0x248 in gdb12. obviously, the addr is normal host address in gdb10.
So how to calculate breakpoint address is key? I guess it's need a target base in -tdep.c.

Thanks,
-David


int
default_memory_insert_breakpoint (struct gdbarch *gdbarch,
 struct bp_target_info *bp_tgt)
{
 CORE_ADDR addr = bp_tgt->placed_address;    ==========================> this bp address is wrong in gdb12.
 const unsigned char *bp;
 gdb_byte *readbuf;
 int bplen;
 int val;

 /* Determine appropriate breakpoint contents and size for this address. */
 bp = gdbarch_sw_breakpoint_from_kind (gdbarch, bp_tgt->kind, &bplen);

 /* Save the memory contents in the shadow_contents buffer and then
 write the breakpoint instruction. */
 readbuf = (gdb_byte *) alloca (bplen);
 val = target_read_memory (addr, readbuf, bplen);
 
If that is the case, then the next question would be, why does it fail in the first place?