Of course (sorry for not including it previously, was in a hurry). This case has been tested with changeset: 7514:b28e7286990c. As suspected, it happens during the copying of the register file when we switch cpus.
(gdb) b isa.hh:194 Breakpoint 1 at 0x1001e3fd3: file isa.hh, line 194. (gdb) cond 1 reg >= SparcISA::ISA::TotalInstIntRegs (gdb) r configs/example/se.py --detailed --caches --l2cache -c /Volumes/JohnHome/code/fibo -F 1 switching cpus Breakpoint 1, SparcISA::ISA::flattenIntIndex (this=0x101a2b8d8, reg=105) at isa.hh:194 194 assert(reg < TotalInstIntRegs); (gdb) bt #0 SparcISA::ISA::flattenIntIndex (this=0x101a2b8d8, reg=105) at isa.hh:194 #1 0x00000001001e4b74 in SimpleThread::readIntReg (this=0x101a2b200, reg_idx=105) at simple_thread.hh:265 #2 0x00000001004e4f9f in ProxyThreadContext<SimpleThread>::readIntReg (this=0x122d0a940, reg_idx=105) at thread_context.hh:370 #3 0x000000010060da82 in O3ThreadContext<O3CPUImpl>::copyArchRegs (this=0x102491710, tc=0x122d0a940) at thread_context_impl.hh:243 #4 0x000000010060cc11 in O3ThreadContext<O3CPUImpl>::takeOverFrom (this=0x102491710, old_context=0x122d0a940) at thread_context_impl.hh:66 #5 0x00000001004d0104 in BaseCPU::takeOverFrom (this=0x1019bfe00, oldCPU=0x122d0d420, ic=0x102457e50, dc=0x1019c1c38) at build/SPARC_SE/cpu/base.cc:348 #6 0x000000010052083f in FullO3CPU<O3CPUImpl>::takeOverFrom (this=0x1019bfe00, oldCPU=0x122d0d420) at build/SPARC_SE/cpu/o3/cpu.cc:1141 #7 0x00000001007bc5a7 in _wrap_SimObject_takeOverFrom (args=0x1020c4c68) at build/SPARC_SE/params/params_wrap.cc:15191 #8 0x00000001011db912 in PyEval_EvalFrameEx () #9 0x00000001011dde75 in PyEval_EvalCodeEx () #10 0x00000001011dbe0d in PyEval_EvalFrameEx () #11 0x00000001011dc26a in PyEval_EvalFrameEx () #12 0x00000001011dc26a in PyEval_EvalFrameEx () #13 0x00000001011dc26a in PyEval_EvalFrameEx () #14 0x00000001011dde75 in PyEval_EvalCodeEx () #15 0x00000001011dc5a9 in PyEval_EvalFrameEx () #16 0x00000001011dde75 in PyEval_EvalCodeEx () #17 0x00000001011dbe0d in PyEval_EvalFrameEx () #18 0x00000001011dde75 in PyEval_EvalCodeEx () #19 0x00000001011ddf96 in PyEval_EvalCode () #20 0x00000001012033f7 in PyRun_StringFlags () #21 0x0000000100748560 in m5Main (argc=9, argv=0x7fff5fbff650) at build/SPARC_SE/sim/init.cc:194 #22 0x0000000100014617 in main (argc=9, argv=0x7fff5fbff650) at build/SPARC_SE/sim/main.cc:57 (gdb) c Continuing. Assertion failed: (reg < TotalInstIntRegs), function flattenIntIndex, file build/SPARC_SE/arch/sparc/isa.hh, line 194. On Tue, Aug 17, 2010 at 9:32 PM, Gabriel Michael Black < [email protected]> wrote: > Could you rerun that inside gdb (using m5.debug preferably) and get a > backtrace? Basically, this is a bounds check during the process of mapping a > register index from an instruction/simulated program perspective down to an > actual storage location managed by the CPU. Something, possibly the > switching logic, seems to be trying to use a bad index, and it would be > helpful to know where the call is coming from and what it's trying to do. > > Gabe > > > Quoting john <[email protected]>: > > Hello, >> >> I've been trying to get fast forwarding to work with SPARC_SE. However, I >> get the following error: >> >> ... >> switching cpus >> Assertion failed: (reg < TotalInstIntRegs), function flattenIntIndex, file >> build/SPARC_SE/arch/sparc/isa.hh, line 194. >> >> This happens both with my own scripts and configs/example/se.py, so I >> doubt >> its a script configuration problem. >> >> Any ideas on what the problem is / how to go about fixing it? Since we're >> switching CPUs of the same ISA the register files ought to be identical, >> are >> they? >> >> Thanks in advance, >> John >> >> > >
_______________________________________________ m5-users mailing list [email protected] http://m5sim.org/cgi-bin/mailman/listinfo/m5-users
