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