Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
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


  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