This is mostly tangential to your question, but if you're working on the CheckerCPU, be sure to get your stuff into the repository. I consider the CheckerCPU abandoned and rotting, and I'm making no particular effort to keep it working since it doesn't work now anyway (at least as far as I know). If you want to make sure it stays functional, get it working in the dev repo and put together some sort of test.

Gabe

Quoting Geoffrey Blake <[email protected]>:

Hey all,

I've been working on getting the CheckerCPU functioning for the ARM
ISA to help with debugging a potential race condition in the O3 cpu.
I have it working in both SE and FS modes when starting simulation
from the beginning with the O3CPU.  I'm now trying to get it fully
functional with checkpoints since one of the test cases I need to
debug is exposed when starting from a checkpoint.

The problem I'm seeing I'd like some help with is when takeOverFrom()
is called for switching from AtomicCPU to the O3CPU. The current
problem I'm seeing is a segfault right after the call to switch CPUs
due to the CheckerCPU not having all its ports created properly during
the initial configuration or when python switches the atomicCPU for
the O3CPU.

My main question is how are objects created in gem5 when using
checkpoints?  Are all the simobjects created during the initial
configuration and just switched with takeOverFrom()?  Or are they
created on demand, for example when the AtomicCPU is about to be
switched out does gem5 then create the O3CPU to switch in?  Since this
seems to happen partly in C++ and partly in python I'm having trouble
following the code.  Any help would be useful in figuring out a
solution on my end.

Geoff
_______________________________________________
gem5-users mailing list
[email protected]
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users



_______________________________________________
gem5-users mailing list
[email protected]
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users

Reply via email to