On Fri, Jan 11, 2013 at 2:17 PM, Nilay Vaish <[email protected]> wrote:
> On Fri, 11 Jan 2013, Steve Reinhardt wrote: > >> I believe the HandyM5Reg value is already serialized as part of the misc >> reg file. I think you could solve the problem with fewer changes just by >> calling decoder->setM5Reg after unserializing the register file. >> > > The misc reg file is part of the isa section of the checkpoint and the isa > is now a separate sim object. The decoder can only be accessed via the > simple thread structure. This means that the isa should be unserialized > before the thread state. I think we do want to rely on the ordering. And > there is no initialization function that is called after loadState() has > been called on the sim objects. If the ISA object knew which CPU it belonged to, it could call cpu->decoder->setM5Reg() in its loadState() method after unserialize(). It looks like it doesn't know, but we could change that. (Actually I missed this recent change... I'm a little unomfortable with it, since it seems to jumble together both ISA traits and ISA-specific state. Looks like we're already running into an unforeseen downside too. And I don't really like the name, something like ISASpecificState would be better if that's really what we want it to be. Anyway, the bottom line here is that that change is recent enough that I don't think we should take that aspect of the code as an inviolable constraint in solving this other problem.) In fact I see now that X86ISA::ISA::unserialize() already calls updateHandyM5Reg(), which calls tc->getDecodePtr()->setM5Reg() when the tc argument is non-NULL. So arguably the problem here is only that this particular call to updateHandyM5Reg() passes in NULL for the tc, since it doesn't know any better. If the ISA object knew which CPU it belonged to, it could set its tc value in init(). Another option is to use the startup() method on the CPU do to this, since that is called after loadState() is called on all objects. That's a little less elegant, IMO, but is perhaps less invasive to the status quo. Steve _______________________________________________ gem5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/gem5-dev
