Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Michael Snyder <msnyder@vmware.com>
To: Kevin Buettner <kevinb@redhat.com>
Cc: "gdb-patches@sourceware.org" <gdb-patches@sourceware.org>
Subject: Re: Should we be able to read simulator memory immediately after a "load" command?
Date: Mon, 28 Jun 2010 22:25:00 -0000	[thread overview]
Message-ID: <4C29213C.8020308@vmware.com> (raw)
In-Reply-To: <20100628130010.360f398d@mesquite.lan>

Kevin Buettner wrote:
> In the course of debugging a program in which the LMA and VMA of
> certain segments differ, we've noticed that simulator memory cannot be
> read immediately after a issuing a "load" command.  One needs to "run"
> the program first in order to be able to access simulator memory.
> 
> In our debugging scenario, the fact that the LMA differs from the VMA
> is only significant in that when they're the same, you tend to get the
> expected results when attempting to read memory immediately after the
> "load" due to the fact that GDB does memory fetches using the exec
> file.   When the LMA and VMA are different, the exec file provides
> access to memory at the VMA addresses, but not at LMA addresses.
> When using the simulator (or a remote target), I would expect to
> be able to read memory located at a valid LMA addresss.  Memory at
> at a VMA address may or may not be available yet; it will most likely be
> initialized early on during execution of the program.
> 
> The code responsible for disallowing access to simulator memory after
> a "load", but before a "run" appears as follows in
> gdbsim_xfer_inferior_memory():
> 
>   /* If no program is running yet, then ignore the simulator for
>      memory.  Pass the request down to the next target, hopefully
>      an exec file.  */
>   if (!target_has_execution)
>     return 0;
> 
> This code was added in a patch from 2006.  See:
> 
>     http://sourceware.org/ml/gdb-patches/2006-10/msg00042.html
> 
> In that posting, Daniel provides a good rationale for that patch as a
> whole, but I did not see any discussion of the portion affecting
> gdbsim_xfer_inferior_memory().
> 
> So, the obvious question... Is there any good reason to prohibit
> access to the simulator's memory immediately after a load?
> 
> (If not, I'll post a patch removing that restriction...)

Hmm, should we substitute "target_has_memory"?

Is that set to TRUE after a load?


  reply	other threads:[~2010-06-28 22:25 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-06-28 20:00 Kevin Buettner
2010-06-28 22:25 ` Michael Snyder [this message]
2010-06-28 23:55   ` Kevin Buettner
2010-06-28 23:57     ` Michael Snyder
2010-06-29  0:46       ` Kevin Buettner
2010-06-28 22:28 ` Mike Frysinger
2010-06-29 19:56 ` Daniel Jacobowitz
2010-07-02 16:46   ` Kevin Buettner
2010-07-02 23:14     ` Kevin Buettner

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=4C29213C.8020308@vmware.com \
    --to=msnyder@vmware.com \
    --cc=gdb-patches@sourceware.org \
    --cc=kevinb@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