Encapsulated gem5-specific code into wrapper functions to separate the
build process (Fail: CMake, gem5: scons). Added some gem5-related FIXMEs.
Another CMake related FIXME added. +some cosmetics.
Change-Id: Id84b480127b1f13aed6a0ee97f3583f410d531c5
In fact, delete should be called in the destructor of each derived class (BochsController and Gem5Controller at the moment).
Additionally, this is the reason why ~SimulatorController is declared as virtual.
git-svn-id: https://www4.informatik.uni-erlangen.de/i4svn/danceos/trunk/devel/fail@2064 8c4709b5-6ec9-48aa-a5cd-a96041d1645a
- The register manager is gone. It's functionality is now encapsulated in the
CPU classes.
- For the client, there is the ConcreteCPU class that encapsulates the access
to the CPU state (including registers) and architecture details. The
correspondig objects for the CPUs inside the simulator can be accessed
through the SimulatorController.getCPU() function.
- Listener got a new ConcreteCPU* member to filter for which CPU the events
should fire. The default NULL is used as wildcard for all aviable CPUs. The
events respectively got a ConcreteCPU* member to indicate which CPU really
fired the event.
- For the server, there is CPUArchitecture to access the architecture details.
git-svn-id: https://www4.informatik.uni-erlangen.de/i4svn/danceos/trunk/devel/fail@1966 8c4709b5-6ec9-48aa-a5cd-a96041d1645a
- FailGem5Device is gone.
- There are now changes directly made to the gem5 source.
- Gem5Connector is a helper class that is compiled inside the gem5 context to workaround problems with gem5 header in fail.
Things that are working:
- BPSingleListener
- MemAccessListener
- Save and restore simulator state
git-svn-id: https://www4.informatik.uni-erlangen.de/i4svn/danceos/trunk/devel/fail@1820 8c4709b5-6ec9-48aa-a5cd-a96041d1645a
