I effectively removed all of my modified code and re-ran simulations
with exactly the same result.
I'll investigate the memPort bit, though I haven't modified memory ports
for any of the basic CPU models at any point.
If it truly is a bug with M5 not supporting checkpointing in ARM_SE with
the simple atomic/timing models, hopefully I'll be able to fix it :)
Thanks for pointing out the memPort issue.
Griffin
On 3/30/2011 11:34 AM, Gabe Black wrote:
The memPort pointer has value 0x6 which is not a real address. It
ultimately probably came from a member variable of a structure or
class which was pointed to with a NULL pointer, or it could ust be a
junk address. You should figure out where memPort is coming from and
that might lead to the real problem.
How have you determined it's not your code if you haven't found the
source of the problem?
Gabe
On 03/30/11 10:27, Griffin Wright wrote:
Gabe et al:
So I've determined that these various issues (segfaults,
system.cpu:locked not being unserializable, and the warning about
system.cpu.workload: M5_pid not being present) are not the result of
any code modifications that I've made.
Focusing on the segfault, which occurs when I try to restore a
checkpoint made while using simple atomic (and using the same to do
the restoration), the following is the gdb trace I get, accompanied
by a few gdb commands. I'm not a debugging expert, and am not sure
what to make of all of this aside from it seeming like a segfault
when trying to load a 'section' back into memory.
-Griffin Wright
-------------------------------------
M5 compiled Mar 29 2011 19:01:25
M5 revision 31a04e5ac4be+ 7866+ default tip
M5 started Mar 30 2011 10:13:44
M5 executing on grwright-desktop
command line: /home/grwright1/Research/m5/build/ARM_SE/m5.debug
configs/SFI/sfi_test.py --at-instruction --checkpoint-restore=100
Running Simulation now
Global frequency set at 1000000000000 ticks per second
0: system.remote_gdb.listener: listening for remote gdb #0 on port 7000
*
warn: optional parameter system.cpu.workload:M5_pid not present*
For more information see: http://www.m5sim.org/warn/aa78cda1
**** REAL SIMULATION ****
*Program received signal SIGSEGV, Segmentation fault.
0x08d25d6b in ObjectFile::loadSection (this=0x94a4ed0, sec=0x94a4efc,
memPort=0x6, addrMask=18446744073709551615) at
build/ARM_SE/base/loader/object_file.cc:75
75memPort->writeBlob(addr, sec->fileImage, sec->size);*
(gdb) list
70ObjectFile::loadSection(Section *sec, Port *memPort, Addr addrMask)
71{
72if (sec->size != 0) {
73Addr addr = sec->baseAddr & addrMask;
74if (sec->fileImage) {
75memPort->writeBlob(addr, sec->fileImage, sec->size);
76}
77else {
78// no image: must be bss
79memPort->memsetBlob(addr, 0, sec->size);
(gdb) print addr
$1 = 32768
(gdb) print sec->size
$2 = 519500
(gdb) print sec->fileImage
$3 = (uint8_t *) 0x97bd8000 "\177ELF\001\001\001"
On 3/29/2011 2:04 PM, Gabe Black wrote:
The M5_pid warning is possibly the symptom of a bug since I would expect
the same build of the simulator to serialize and then unserialize it
symmetrically, not just to unserialize it. Basically, it's a way to
force the pid assigned to the simulated process which can be returned by
certain system calls. There are circumstances where that's useful, but
it should be harmless for you.
M5 should never get a segfault (other than the simulated kind) so that
part is a more serious bug. Please let us know what you find,
particularly if you haven't modified any code.
Gabe
_______________________________________________
m5-users mailing list
[email protected]
http://m5sim.org/cgi-bin/mailman/listinfo/m5-users
_______________________________________________
m5-users mailing list
[email protected]
http://m5sim.org/cgi-bin/mailman/listinfo/m5-users
_______________________________________________
m5-users mailing list
[email protected]
http://m5sim.org/cgi-bin/mailman/listinfo/m5-users
