Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: "Maciej W. Rozycki" <macro@codesourcery.com>
To: Jan Kratochvil <jan.kratochvil@redhat.com>
Cc: Pedro Alves <palves@redhat.com>, <gdb-patches@sourceware.org>
Subject: Re: [patch] Re: Regression for gdbserver  [Re: [PATCH] Linux/gdbserver: Fix memory read ptrace fallback issues]
Date: Tue, 22 May 2012 23:34:00 -0000	[thread overview]
Message-ID: <alpine.DEB.1.10.1205230017560.11227@tp.orcam.me.uk> (raw)
In-Reply-To: <20120522204235.GA31756@host2.jankratochvil.net>

On Tue, 22 May 2012, Jan Kratochvil wrote:

> > it's difficult to chase something you can't reproduce.
> 
> I see that patch
> 	[RFC patch] non-release srctrees: --enable-targets=all & 64bit & -lmcheck
> 	http://sourceware.org/ml/gdb-patches/2012-05/msg00714.html
> 
> should include also better CFLAGS.  But the patch does not seem to go in so
> far so we may continue with mail threads like this one.

 Hmm, it wouldn't have triggered at the compilation time probably anyway.  
I have switched to --enable-targets=all already, based on some past 
experience.

> >  I think however, that this memcpy call needs a rewrite now, I find your 
> > proposal unreadable.
> 
> I find the whole function unreadable but this was true also before your patch.
> But I did not try to change that in this fix up.  It also has 64-bit unsafe
> bug using 'int' for memory sizes.

 As noted in the original thread, this whole stuff asks for a rewrite and 
that will be a good opportunity to make it more readable too.

 The 'int' bug hardly ever triggers probably, as you'd have to request 
more than 2GB in one go that is I believe very rare, but I agree that 
should be size_t instead.  You'd have to check the callers if they don't 
cope with that limitation already somehow however -- though I think it's 
unlikely and I am too lazy to go chase it right now.  It could be that 
this is how the RSP has been specified too.
 
> I find always more clear to calculate everything as START ADDRESS and ONE BYTE
> AFTER THE LAST ADDRESS till the very last moment.

 That indeed, or START & SIZE in bytes.

> >   /* Copy appropriate bytes out of the buffer.  */
> >   if (i > 0)
> >     {
> >       i *= sizeof (PTRACE_XFER_TYPE);
> >       i -= memaddr & (sizeof (PTRACE_XFER_TYPE) - 1);
> >       memcpy (myaddr,
> > 	      (char *) buffer + (memaddr & (sizeof (PTRACE_XFER_TYPE) - 1)),
> > 	      i < len ? i : len);
> >     }
> > 
> > ?
> 
> This code has equal functionality in my local testing.

 And has passed my regression testing on mips-linux-gnu and i686-linux-gnu 
as well.  It did fix a number of failures on the latter, sorry for not 
testing my change on another target before, I should have.  I have now 
checked it in, the actual diff follows.

2012-05-22  Maciej W. Rozycki  <macro@codesourcery.com>

	* linux-low.c (linux_store_registers): Avoid the copying sequence
	when no data has been retrieved by ptrace.

  Maciej

gdb-gdbserver-linux-read-memory-ptrace-fix.diff
Index: gdb-fsf-trunk-quilt/gdb/gdbserver/linux-low.c
===================================================================
--- gdb-fsf-trunk-quilt.orig/gdb/gdbserver/linux-low.c	2012-05-22 19:20:59.000000000 +0100
+++ gdb-fsf-trunk-quilt/gdb/gdbserver/linux-low.c	2012-05-22 21:15:36.545454255 +0100
@@ -4447,11 +4447,14 @@ linux_read_memory (CORE_ADDR memaddr, un
   ret = errno;
 
   /* 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)),
-	  i < len ? i : len);
+  if (i > 0)
+    {
+      i *= sizeof (PTRACE_XFER_TYPE);
+      i -= memaddr & (sizeof (PTRACE_XFER_TYPE) - 1);
+      memcpy (myaddr,
+	      (char *) buffer + (memaddr & (sizeof (PTRACE_XFER_TYPE) - 1)),
+	      i < len ? i : len);
+    }
 
   return ret;
 }


  reply	other threads:[~2012-05-22 23:34 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-05-16 22:57 [PATCH] Linux/gdbserver: Fix memory read ptrace fallback issues Maciej W. Rozycki
2012-05-18 16:53 ` Pedro Alves
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 [this message]
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=alpine.DEB.1.10.1205230017560.11227@tp.orcam.me.uk \
    --to=macro@codesourcery.com \
    --cc=gdb-patches@sourceware.org \
    --cc=jan.kratochvil@redhat.com \
    --cc=palves@redhat.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