Hi,

This is because of address space info is not saved during serialization.

In src/sim/process.cc,

In void Process::serialize(CheckpointOut &cp) const, add the following lines

    paramOut(cp, "mem_state.brk_point", memState->getBrkPoint());
    paramOut(cp, "mem_state.stack_base", memState->getStackBase());
    paramOut(cp, "mem_state.stack_size", memState->getStackSize());
    paramOut(cp, "mem_state.max_stack_size", memState->getMaxStackSize());
    paramOut(cp, "mem_state.stack_min", memState->getStackMin());
    paramOut(cp, "mem_state.next_thread_stack_base",
memState->getNextThreadStackBase());
    paramOut(cp, "mem_state.mmap_end", memState->getMmapEnd());


In void Process::unserialize(CheckpointIn &cp), add the following lines

    Addr _brkPoint;
    Addr _stackBase;
    Addr _stackSize;
    Addr _maxStackSize;
    Addr _stackMin;
    Addr _nextThreadStackBase;
    Addr _mmapEnd;

    paramIn(cp, "mem_state.brk_point", _brkPoint);
    paramIn(cp, "mem_state.stack_base", _stackBase);
    paramIn(cp, "mem_state.stack_size", _stackSize);
    paramIn(cp, "mem_state.max_stack_size", _maxStackSize);
    paramIn(cp, "mem_state.stack_min", _stackMin);
    paramIn(cp, "mem_state.next_thread_stack_base", _nextThreadStackBase);
    paramIn(cp, "mem_state.mmap_end", _mmapEnd);

    memState->setBrkPoint(_brkPoint);
    memState->setStackBase(_stackBase);
    memState->setStackSize(_stackSize);
    memState->setMaxStackSize(_maxStackSize);
    memState->setStackMin(_stackMin);
    memState->setNextThreadStackBase(_nextThreadStackBase);
    memState->setMmapEnd(_mmapEnd);


On Mon, Nov 13, 2017 at 9:33 PM, Gabe Black <gabebl...@google.com> wrote:

> Hi Austin. It sounds like some sort of bug in the Process object or
> FuncPageTable object's serialization code, although that's just a guess on
> my part. If it works in an older version of gem5, you could try binary
> searching through the history and find the point where it stopped working.
> I took a quick look at the existing implementation and didn't see anything
> that was obviously wrong.
>
> Gabe
>
> On Mon, Nov 13, 2017 at 3:28 PM, Austin Harris <austinhar...@utexas.edu>
> wrote:
>
>> Hello,
>>
>> I've been running into an issue with the latest gem5 git master when
>> running gobmk from spec2006. The issue occurs when restoring from a
>> checkpoint that I created by adding m5_checkpoint to the gobmk source
>> (specifically right before the switch(playmode) in interface/main.c.) If I
>> let the simulation run from the beginning rather than restoring from a
>> checkpoint, the error never occurs.
>>
>> I run the following command to generate the checkpoint:
>>
>> ../build/ARM/gem5.opt ../configs/example/se.py --cpu-type=AtomicSimpleCPU
>> --mem-size=4GB --mem-type=SimpleMemory --cpu-clock=1GHz --sys-clock=1GHz -c
>> ./gobmk_base.aarch64-linux-gnu -o ' --quiet --mode gtp ' --input=13x13.tst
>>
>> And this command to restore from the checkpoint:
>>  ../build/ARM/gem5.opt ../configs/example/se.py --cpu-type=O3_ARM_v7a_3
>> --caches --l2cache --mem-size=4GB --mem-type=SimpleMemory --cpu-clock=1GHz
>> --sys-clock=1GHz --l1d_size=32kB -r1 -c ./gobmk_base.aarch64-linux-gnu -o '
>> --quiet --mode gtp ' --input=13x13.tst
>>
>>
>> Once I restore from the checkpoint and begin simulating, I get the below
>> error:
>> fatal: FuncPageTable::allocate: addr 0x3fffff0000 already mapped
>>
>> I tried the same experiment with x86 and RISC-V and all got the already
>> mapped error. I also tried MinorCPU and TimingSimpleCPU to no avail.
>>
>> However, if I checkout the 2015_09_03 tag, I am able to successfully
>> restore and run the same binary without error.
>>
>> I noticed there was some refactoring of serialize added here in between
>> the working tag and the latest master: http://reviews.gem5.org/r/2861,
>> however I wasn't able to narrow down what could be causing the issue.
>>
>> I tried the suggestion to print out the Syscall debug flags here:
>> https://www.mail-archive.com/gem5-users@gem5.org/msg13627.html, however
>> the output just shows that mmap is being called with that range:
>> 12384702000: system.switch_cpus: T0 : syscall mmap2 called w/arguments 0,
>> 65536, 3, 34, 18446744073709551615, 0
>> 12384702000: system.switch_cpus: T0 : syscall  mmap range is 0x3fffff0000
>> - 0x3fffffffff
>>
>> I also tried larger memory sizes up to 16GB as well as changing the
>> maxStackSize in sim/Process.py and max_stack_size in arch/arm/process.cc to
>> 128MB, but the same error persists.
>>
>> Does anyone have any pointers for how to debug this issue, or has anyone
>> else had similar issues with gobmk or other spec2006 benchmarks?
>>
>> Thanks!
>> Austin
>>
>> _______________________________________________
>> gem5-users mailing list
>> gem5-users@gem5.org
>> http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
>>
>
>
> _______________________________________________
> gem5-users mailing list
> gem5-users@gem5.org
> http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
>
_______________________________________________
gem5-users mailing list
gem5-users@gem5.org
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users

Reply via email to