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

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

[Kevin Buettner]

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...)

Kevin

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

[Michael Snyder]

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?

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

[Mike Frysinger]

[-- Attachment #1: Type: Text/Plain, Size: 225 bytes --]

On Monday, June 28, 2010 16:00:10 Kevin Buettner wrote:
> So, the obvious question... Is there any good reason to prohibit
> access to the simulator's memory immediately after a load?

i'd like this restriction removed
-mike

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

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

[Kevin Buettner]

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".

Kevin

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

[Michael Snyder]

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.   ;-)

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

[Kevin Buettner]

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."));
 

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

[Daniel Jacobowitz]

On Mon, Jun 28, 2010 at 01:00:10PM -0700, Kevin Buettner wrote:
> 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().

I'm just guessing, but my guess is that removing the check breaks
reading memory between "tar sim" and "load", and previously we would
have read from the executable file.

If I bothered to make the change it was probably because of the
testsuite...

-- 
Daniel Jacobowitz
CodeSourcery

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

[Kevin Buettner]

On Tue, 29 Jun 2010 15:56:03 -0400
Daniel Jacobowitz <dan@codesourcery.com> wrote:

> On Mon, Jun 28, 2010 at 01:00:10PM -0700, Kevin Buettner wrote:
> > 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().
> 
> I'm just guessing, but my guess is that removing the check breaks
> reading memory between "tar sim" and "load", and previously we would
> have read from the executable file.

Yes, that makes sense.

> If I bothered to make the change it was probably because of the
> testsuite...

My own testing showed some regressions using that simple patch
that I posted earlier.  To that patch I added sim specific
`has_memory' and `has_all_memory' methods which simply return
true when `program_loaded' is true.  I also took Michael's advice
and changed the test in gdbsim_xfer_inferior_memory to instead
call `to_has_memory'.

This worked great but for two regressions in gdb.base/multi.exp.  The
problem was that `program_loaded' was a global and needed to be turned
into a per-inferior instance variable.  I did a bit more work to fix
those regressions and now have a patch which allows us to have
multiple simulator instances.  It only works for certain simulators.
E.g. mips and frv work, but powerpc and arm do not.  v850 should
work, but doesn't for some reason.  (My guess is that there's an
inadvertent global lurking in the v850 sim code somewhere.) I know
without trying them that rx and m32c will also not support multiple
instances.  I haven't looked closely at the others yet.

I'll post it as a two-parter, the first part moves the static globals
into a per-inferior struct and makes the necessary adjustments to the
code.  The second part will add `has_memory' and `has_all_memory'
methods in addition to adjusting gdbsim_xfer_inferior_memory(), thus
fixing the problem that lead me down this path at the outset.

Kevin

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

[Kevin Buettner]

On Fri, 2 Jul 2010 09:46:21 -0700
Kevin Buettner <kevinb@redhat.com> wrote:

> I'll post it as a two-parter, the first part moves the static globals
> into a per-inferior struct and makes the necessary adjustments to the
> code.  The second part will add `has_memory' and `has_all_memory'
> methods in addition to adjusting gdbsim_xfer_inferior_memory(), thus
> fixing the problem that lead me down this path at the outset.

See:

    http://sourceware.org/ml/gdb-patches/2010-07/msg00059.html

and

    http://sourceware.org/ml/gdb-patches/2010-07/msg00060.html

Kevin