public inbox for gdb-patches@sourceware.org
 help / color / mirror / Atom feed
From: Pedro Alves <palves@redhat.com>
To: "Abid, Hafiz" <Hafiz_Abid@mentor.com>
Cc: "gdb-patches@sourceware.org" <gdb-patches@sourceware.org>,
	       "Mirza, Taimoor" <Taimoor_Mirza@mentor.com>
Subject: Re: [patch] Disassembly improvements
Date: Thu, 10 Oct 2013 13:34:00 -0000	[thread overview]
Message-ID: <5256ACED.7040402@redhat.com> (raw)
In-Reply-To: <EB3B29AD43CA924DA27099BC85192376E0705106@EU-MBX-03.mgc.mentorg.com>

On 10/10/2013 02:14 PM, Abid, Hafiz wrote:
> Hi Pedro,
> I am attaching the patch that was mentioned in the following thread. I resurrected it from our internal repo, did a bit of manual testing and run the regression suite without any problem. It basically reads memory from the target in a buffer in gdb_disassembly and tries to use this buffer in dis_asm_read_memory instead of reading from the target. This saves us on repeated memory read calls. The problem was noted when eclipse was trying to fill its disassembly view.
> https://sourceware.org/ml/gdb-patches/2013-10/msg00221.html

Thanks.

> +  /* Assume the disassembler always read memory forwards.  If we

"always reads"

> +     failed to read a buffer line in a previous call, assume we're
> +     reading close to the end of a mapped page or section, and so it's
> +     useless to keep retrying reading that buffer line.  Simply
> +     fallback to reading directly from target memory.  */

Should be "retrying to read", I think.


> +  if (info->buffer_length > 0)
> +    {
> +      while (len)
> +	{
> +	  if (memaddr >= info->buffer_vma
> +	      && memaddr < info->buffer_vma + info->buffer_length)
> +	    {
> +	      unsigned int offset = (memaddr - info->buffer_vma);
> +	      unsigned int l = min (len, info->buffer_length - offset);
> +
> +	      memcpy (myaddr, info->buffer + offset, l);
> +
> +	      memaddr += l;
> +	      myaddr += l;
> +	      len -= l;
> +
> +	      if (len == 0)
> +		return 0;
> +	    }
> +	  else
> +	    {
> +	      int rval;
> +	      unsigned int len = info->buffer_length;
> +
> +	      /* Try fetching a new buffer line from the target.  */

Hmm, this seems to miss making sure LEN doesn't read beyond the
original requested memory range.  It'd be good to add that.

That "unsigned int len" variable shadows the function's "len"
parameter.  It'd be good to rename it.

> +
> +	      /* If we fail reading memory halfway, we'll have clobbered
> +		 the buffer, so don't trust it anymore, even on fail.  */
> +	      info->buffer_length = 0;
> +	      rval = target_read_memory (memaddr, info->buffer, len);
> +	      if (rval == 0)
> +		{
> +		  info->buffer_vma = memaddr;
> +		  info->buffer_length = len;
> +		}
> +	      else
> +		{
> +		  /* Read from target memory directly from now on.  */
> +		  break;
> +		}
> +	    }
> +	}
> +    }
>    return target_read_memory (memaddr, myaddr, len);
>  }


-- 
Pedro Alves

  reply	other threads:[~2013-10-10 13:34 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-10-10 13:14 Abid, Hafiz
2013-10-10 13:34 ` Pedro Alves [this message]
2013-10-10 13:57   ` Abid, Hafiz
2013-10-10 14:52     ` Pedro Alves
2013-10-10 15:13       ` Pedro Alves
2013-10-11 16:45         ` Abid, Hafiz
2013-10-11 21:12           ` Pedro Alves
2013-10-11 21:34 ` Doug Evans
2013-10-14  9:37   ` Abid, Hafiz
2013-10-14 14:42   ` Pedro Alves
2013-10-16  1:16     ` Doug Evans
2013-10-16  7:53       ` Yao Qi
2013-10-16 12:08         ` Pedro Alves
2013-10-16 13:23           ` Yao Qi
2013-10-18 10:24           ` Yao Qi
2013-10-18 18:25             ` Pedro Alves
2013-10-19  1:55               ` Yao Qi
2013-10-25  7:56                 ` Doug Evans
2013-10-16 12:02       ` Pedro Alves

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=5256ACED.7040402@redhat.com \
    --to=palves@redhat.com \
    --cc=Hafiz_Abid@mentor.com \
    --cc=Taimoor_Mirza@mentor.com \
    --cc=gdb-patches@sourceware.org \
    /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).