* why ptrace read failed to read debugging process memory? @ 2022-03-10 6:40 周春明(日月) 2022-03-10 10:05 ` Pedro Alves 0 siblings, 1 reply; 3+ messages in thread From: 周春明(日月) @ 2022-03-10 6:40 UTC (permalink / raw) To: 周春明(日月), Simon Marchi, Gdb-patches, gdb-patches Cc: Louis-He, Dominique Quatravaux, Sam Warner 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 ^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: why ptrace read failed to read debugging process memory? 2022-03-10 6:40 why ptrace read failed to read debugging process memory? 周春明(日月) @ 2022-03-10 10:05 ` Pedro Alves 2022-03-10 10:34 ` 回复:why " 周春明(日月) 0 siblings, 1 reply; 3+ messages in thread From: Pedro Alves @ 2022-03-10 10:05 UTC (permalink / raw) To: 周春明(日月), Simon Marchi, Gdb-patches, gdb-patches Cc: Louis-He, Dominique Quatravaux, Sam Warner 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? ^ permalink raw reply [flat|nested] 3+ messages in thread
* 回复:why ptrace read failed to read debugging process memory? 2022-03-10 10:05 ` Pedro Alves @ 2022-03-10 10:34 ` 周春明(日月) 0 siblings, 0 replies; 3+ messages in thread From: 周春明(日月) @ 2022-03-10 10:34 UTC (permalink / raw) To: Pedro Alves, Simon Marchi, Gdb-patches, gdb-patches Cc: Louis-He, Dominique Quatravaux, Sam Warner ------------------------------------------------------------------ 发件人: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? ^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2022-03-10 10:34 UTC | newest] Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2022-03-10 6:40 why ptrace read failed to read debugging process memory? 周春明(日月) 2022-03-10 10:05 ` Pedro Alves 2022-03-10 10:34 ` 回复:why " 周春明(日月)
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).