Re: Should we be able to read simulator memory immediately after a "load" command?

[Kevin Buettner <kevinb@redhat.com>]

On Mon, 28 Jun 2010 16:56:56 -0700
Michael Snyder <msnyder@vmware.com> wrote:

> Kevin Buettner wrote:
> > On Mon, 28 Jun 2010 15:25:00 -0700
> > Michael Snyder <msnyder@vmware.com> wrote:
> > 
> >> Hmm, should we substitute "target_has_memory"?
> >>
> >> Is that set to TRUE after a load?
> > 
> > If default_child_has_memory() is used, which is currently the case for
> > the remote-sim target, it will not return TRUE after a "load", but
> > before a "run".
> 
> Hmmm.  That sucks.   ;-)

In my opinion, the check in question can simply be removed.  See below.

Note that should the attempted memory read fail and return 0 bytes,
the next target down the target stack will be consulted.  (That's true
though only so long as it's not running.  Once it's running, then
memory accesses are restricted to the current target.  To see why this
is so, examine the code around the to_has_all_memory() check in
memory_xfer_partial().)

	* remote-sim.c (gdbsim_xfer_inferior_memory): Allow access
	to simulator once the program has been loaded, though not
	necessarily running.

Index: remote-sim.c
===================================================================
RCS file: /cvs/src/src/gdb/remote-sim.c,v
retrieving revision 1.96
diff -u -p -r1.96 remote-sim.c
--- remote-sim.c	16 May 2010 21:11:14 -0000	1.96
+++ remote-sim.c	29 Jun 2010 00:32:25 -0000
@@ -764,12 +764,6 @@ gdbsim_xfer_inferior_memory (CORE_ADDR m
 			     int write, struct mem_attrib *attrib,
 			     struct target_ops *target)
 {
-  /* 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;
-
   if (!program_loaded)
     error (_("No program loaded."));