From: Pedro Alves <palves@redhat.com>
To: "Maciej W. Rozycki" <macro@codesourcery.com>
Cc: gdb-patches@sourceware.org
Subject: Re: [PATCH] Linux/gdbserver: Fix memory read ptrace fallback issues
Date: Fri, 18 May 2012 16:53:00 -0000 [thread overview]
Message-ID: <4FB67E6D.2040406@redhat.com> (raw)
In-Reply-To: <alpine.DEB.1.10.1205161642060.11227@tp.orcam.me.uk>
Hi Maciej,
On 05/16/2012 11:56 PM, Maciej W. Rozycki wrote:
> While trying to investigate suspicious MIPS16/Linux test suite results
> noted with the recent MIPS ISA bit solution proposal I have come across
> this problem in gdbserver. It contributed to about 2550 failures per
> multilib.
>
> In linux_read_memory we make a two-way choice as to how we read
> debuggee's memory -- we prefer pread64 or lseek/read of /proc/<pid>/mem
> and failing that we resort to a long boring series of PEEKTEXT ptrace
> requests. We use this in particular in linux_qxfer_libraries_svr4 to
> access names of shared libraries loaded. There we rely on
> linux_read_memory to return data in the buffer provided even if the
> function wasn't able to read the whole number of bytes requested.
>
> This has two problems as I revealed. If any call in the pread64 fails
> then the supplied buffer is obviously not filled.
It looks like the pread64/lseek/read path actually reads directly
into MYADDR (the supplied buffer).
> Then if the ptrace
> fallback path is not able to retrieve the whole number of bytes requested,
> then it does not supply partially retrieved data to the buffer. This is
> the scenario that I observed.
Right.
> The change below addresses these two problems. Any data successfully
> retrieved by the ptrace loop is copied over to the user buffer even if
> linux_read_memory returns unsuccessfully. If pread64 successfully
> retrieves any data, then ptrace is not used to read that data again, the
> attempt to read data is resumed at the point where pread64 stopped. This
> will normally not retrieve any further data as pread64 would have provided
> that (internally, in the Linux kernel, the read handlers for
> /proc/<pid>/maps special files are implemented as a wrapper around the
> very same worker function that the PEEKTEXT ptrace request uses.
So how about just returning immediately if reading from /proc manages to
read something? From what you say, the PEEKTEXT fallback then won't just
normally fail; it'll _always_ fail. I suspect that'd make the code a bit
simpler.
> /* Copy appropriate bytes out of the buffer. */
> + i *= sizeof (PTRACE_XFER_TYPE);
> + i -= memaddr & (sizeof (PTRACE_XFER_TYPE) - 1);
> memcpy (myaddr,
> (char *) buffer + (memaddr & (sizeof (PTRACE_XFER_TYPE) - 1)),
> - len);
> + i < len ? i : len);
>
> - return 0;
> + return errno;
You shouldn't assume that "errno" is preserved across library
calls (memcpy in this case).
> }
>
--
Pedro Alves
next prev parent reply other threads:[~2012-05-18 16:53 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-05-16 22:57 Maciej W. Rozycki
2012-05-18 16:53 ` Pedro Alves [this message]
2012-05-18 18:46 ` Maciej W. Rozycki
2012-05-18 20:11 ` Pedro Alves
2012-05-22 0:05 ` Maciej W. Rozycki
2012-05-22 8:04 ` Regression for gdbserver [Re: [PATCH] Linux/gdbserver: Fix memory read ptrace fallback issues] Jan Kratochvil
2012-05-22 12:43 ` Maciej W. Rozycki
2012-05-22 19:35 ` [patch] " Jan Kratochvil
2012-05-22 20:06 ` Maciej W. Rozycki
2012-05-22 20:42 ` Jan Kratochvil
2012-05-22 23:34 ` Maciej W. Rozycki
2012-05-23 5:29 ` Jan Kratochvil
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=4FB67E6D.2040406@redhat.com \
--to=palves@redhat.com \
--cc=gdb-patches@sourceware.org \
--cc=macro@codesourcery.com \
/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