From: "周春明(日月)" <riyue.zcm@alibaba-inc.com>
To: "Pedro Alves" <pedro@palves.net>,
"Simon Marchi" <simon.marchi@polymtl.ca>,
"Gdb-patches"
<gdb-patches-bounces+riyue.zcm=alibaba-inc.com@sourceware.org>,
"gdb-patches" <gdb-patches@sourceware.org>
Cc: "Louis-He" <1726110778@qq.com>,
"Dominique Quatravaux" <dominique.quatravaux@epfl.ch>,
"Sam Warner" <samuel.r.warner@me.com>
Subject: 回复:why ptrace read failed to read debugging process memory?
Date: Thu, 10 Mar 2022 18:34:53 +0800 [thread overview]
Message-ID: <8fae479b-2ce7-4567-b15d-729b35eb41b3.riyue.zcm@alibaba-inc.com> (raw)
In-Reply-To: <ee17dcb4-3cd4-caab-892b-8dfdc2d0ca09@palves.net>
------------------------------------------------------------------
发件人: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?
prev parent reply other threads:[~2022-03-10 10:34 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-03-10 6:40 why " 周春明(日月)
2022-03-10 10:05 ` Pedro Alves
2022-03-10 10:34 ` 周春明(日月) [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=8fae479b-2ce7-4567-b15d-729b35eb41b3.riyue.zcm@alibaba-inc.com \
--to=riyue.zcm@alibaba-inc.com \
--cc=1726110778@qq.com \
--cc=dominique.quatravaux@epfl.ch \
--cc=gdb-patches-bounces+riyue.zcm=alibaba-inc.com@sourceware.org \
--cc=gdb-patches@sourceware.org \
--cc=pedro@palves.net \
--cc=samuel.r.warner@me.com \
--cc=simon.marchi@polymtl.ca \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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).