This quick fix is necessary to let gem5 compile again. Instead of passing
NULL to onInterrupt(), a proper fix should pass the currently active
ConcreteCPU instance.
Change-Id: Ie4322fd98cb7b12309a21a2dd431f9bdc84efaf8
The file dis_tables.h does define several macros with very generic
names (I1, I2). These macros interfere in certain situations with the
boost headers. Therefore, we simply undef all those xmacro arguments,
like it should be done.
Change-Id: Iddf74f04ec016a7ea5de5a66543b670a8992a5d6
This change introduces a fake iobus device into gem5 to prevent
it from crashing on bogus I/O memory accesses.
Change-Id: Ie69e3191bdd917cc681269852937a5a3820a93fb
This change fixes another Bochs crash in the floppy controller,
triggered by one out of 670 million experiments in my current
campaign.
Change-Id: I8a2ff78c9d2c8fca12eefb97f508bc213373bbfa
In former versions, the aforementioned image was 'required' to run
gem5 although it wasn't actually used at all. With the new python
script fail_fs.py, it suffices to start gem5 on a target foo.elf by
simply typing $ ../scripts/run-gem5.sh path/to/target/foo.elf
Change-Id: I7f48460e50d48d55fe22f2381e2ae8aec8510233
(Debian 7.1 comes with gcc 4.7.2) However, we are faking a gcc v4.4.5
but the gem5 build system only adds the '-Wno-unused-but-set-variable'
flag in case of a gcc >= v4.6. Now, this flag will always be appended.
(Older gcc versions should ignore the flag or emit a warning but will
continue to run.)
Change-Id: I7021e08019951375c7e8b56d0f875191f904971d
The build system now allows incremental gem5 builds. Unfortunately,
the current solution always requires re-linking the executable.
Without the enforcement of re-linking, the fail code will be rebuilt
but not linked into gem5.
The number of cores for building gem5 is derived from /proc/cpuinfo.
As before, only the gem5.debug configuration is supported.
Change-Id: Ib13b15d1ecd62196eb251e0fd00953f4eb052feb
This changes allows us to compile the gem5 simulator with ag++. It
was tested with ag++ v0.8, built Apr 18 2013. Most of the changes
are preprocessor directives like #ifndef __puma which have been
inserted into the gem5 code. Unfortunately, a python script and a
SWIG input file have been patched, too.
Additionally, the CMake file has been updated. A single call to
"make" now invokes the ag++ (instead of the g++) compiler front
end. The new CMake target "gem5-allclean" should be used to clean
the current project when building FailGem5. In addition to cleaning
the Fail build directory, it also invokes "scons -c" in the gem5
build directory; that is, gem5 is cleaned as well.
Change-Id: I20a92f025f34f626b81e30f2c873baeba189f83b
Now, the gem5 implementation equals the Bochs variant. Note that its
necessary to enable CONFIG_EVENTS_BREAKPOINTS_RANGE in order to use
range breakpoints.
In addition, gem5 distinguishes between macro- and microops. With the
new implemenation, onBreakpoint is only called when a macroop changes.
Change-Id: Ib86d1802fc70c20d22ca1a1ece0e8d1221b2e7db
This reverts the solution of a former commit (see git hash e1f6601d8494bcb002e89543a9334e053f0e69d3). All additional changes proposed in that commit have been deleted and the major work is now done by the aspect header BreakRepeatInstr.ah: It ensures the condition in the methods repeat() and repeat_ZF() if (BX_CPU_THIS_PTR async_event) ... to be always true which causes Bochs to leave these methods immediately. This, in turn, involves a call to defineCPULoopJointPoint(), yielding a breakpoint event in Fail.
git-svn-id: https://www4.informatik.uni-erlangen.de/i4svn/danceos/trunk/devel/fail@2009 8c4709b5-6ec9-48aa-a5cd-a96041d1645a
- Gem5 now has two different implementation for breakpoints.
- If only BPSingleListener are used, gem5 Breakpoints are used
- If BPRangeListener are used, gem5 calls onBreakpoint() in every simulated instruction
git-svn-id: https://www4.informatik.uni-erlangen.de/i4svn/danceos/trunk/devel/fail@2003 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
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
