- 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
This allows single-stepping through REP/REPZ/REPNZ iterations. We mainly
need this for a little more realistic timing model when, e.g., copying
large memory areas with REP MOVSB.
Be aware that memory-access tracing only works reliably for REPxx-prefixed
instructions if Bochs was configured with --disable-repeat-speedups, as
this Bochs optimization completely circumvents the usual memory access
paths.
git-svn-id: https://www4.informatik.uni-erlangen.de/i4svn/danceos/trunk/devel/fail@1885 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
We need to be able to grep for our manual changes. It doesn't help to
have variations with "TUDOS" or "BOCHS-MODIFIED" around. Please
understand "// DanceOS" comments as an abbreviation for "this code was
manually modified and needs to be manually ported once we switch to a
newer version of Bochs."
git-svn-id: https://www4.informatik.uni-erlangen.de/i4svn/danceos/trunk/devel/fail@1747 8c4709b5-6ec9-48aa-a5cd-a96041d1645a
does not account for arrays of instructions provided
by one virtual instruction trace cache entry ->
passing the current instruction directly.
ALUInstr not yet completely tested.
git-svn-id: https://www4.informatik.uni-erlangen.de/i4svn/danceos/trunk/devel/fail@1704 8c4709b5-6ec9-48aa-a5cd-a96041d1645a
This is a precaution to avoid current and future naming conflicts with
common system libraries. libutil (part of libc) is the first, but probably
not the last example that already caused trouble twice.
git-svn-id: https://www4.informatik.uni-erlangen.de/i4svn/danceos/trunk/devel/fail@1614 8c4709b5-6ec9-48aa-a5cd-a96041d1645a
The FailBochs client is not linked by the Bochs build system anymore, but
by our cmake scripts (make fail-client):
- All Bochs libraries are merged into libfailbochs.a (a new target
within the Bochs Autotools scripts).
- The previous libfail.a is *not* a merge of all Fail* libraries anymore,
but pulls these in via library dependencies.
Additionally I did a lot of build system cleanup, e.g. additional external
libraries may now be pulled in where they're needed.
git-svn-id: https://www4.informatik.uni-erlangen.de/i4svn/danceos/trunk/devel/fail@1390 8c4709b5-6ec9-48aa-a5cd-a96041d1645a
