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
