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
libmysqlclient-dev (or libmariadbclient-dev) is needed to build Fail*.
A running MySQL/MariaDB server to talk to is needed for the
fault-space pruning tools and the DatabaseCampaign, too, but that's a
runtime dependency.
Change-Id: I1f7fbdaf20b49370039e8d27a07a8785e0f052b5
This commit introduces a virtual dtor in the ArmCPUState class to
prevent the compiler from producing the following warning:
"deleting object of polymorphic class type 'fail::Gem5ArmCPU' which
has non-virtual destructor might cause undefined behaviour"
Change-Id: I5029662064e72ae87a9f0e36aeaa309e4cb2291b
(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
It is no longer required (and recommended) to write a dependency
check (using conditional compilation) in the experiment code. Instead,
the Fail code performs these checks itself. If an experiment is
compiled without having the required configuration flags set to
enabled, the compiler emits an error. This is because the constructors
of unused listener classes are declared as protected. (Note that
this works only because the Fail code does not create any listeners.)
In a next step, one should remove all the dependency guards in the
existing experiments (not needed anymore).
Change-Id: I1331813a432a752322d510b4102da53ff53294f0
Doxygen skips undesired directories and files now. In addition, the
documentation of the "fail" namespace has been fixed. Note that there
are still several warnings (due to incomplete documentations) in the
Doxygen output.
Change-Id: Idad4f1ecff453765b307fa40a5c1cebc0c2ce2bb
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
It is a simple and short experiment that performs single stepping
through the target. It is designed to be used with gem5 (+ ARM).
Change-Id: Id48b2b087a3650bd0298454ff168c0dbdaaae0c8
The previous implementation wasn't in a working state because
the register content retrieval was buggy. (For example, RT_FP
does *not* denote a "floating point" register. Instead, it is
the frame pointer!)
Change-Id: I31fd80d374c945adaf35b47958d6437a8e2d48c3
Now, the gem5 implementation equals the Bochs variant. Note that it's
*not* necessary to enable CONFIG_EVENTS_BREAKPOINTS_RANGE in order to
use range breakpoints.
In addition, gem5 distinguishes between macro- and microops. With the
new implementation, onBreakpoint() is only called when a macroop
changes.
Change-Id: Ib86d1802fc70c20d22ca1a1ece0e8d1221b2e7db
It is a simple and short experiment that performs single stepping
through the target. It is designed to be used with gem5 (+ ARM).
Change-Id: Id48b2b087a3650bd0298454ff168c0dbdaaae0c8
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
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
At the moment, the experiment only works with a hard-coded address for the _stext symbol because the ElfReader cannot extract the symbol's address from the elf-binary. The experiment has been tested locally with PREREQUISITES = 1 and PREREQUISITES = 0. In the latter case, the test only considered the client/server communication, i.e., no FI has been performed at all (NOT tested yet).
git-svn-id: https://www4.informatik.uni-erlangen.de/i4svn/danceos/trunk/devel/fail@2066 8c4709b5-6ec9-48aa-a5cd-a96041d1645a
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 includes of these headers have already been removed from the experiments. In the current code, the content of the header BochsRegister.hpp is rather simply copied to x86/Architecture.hpp. It is therefore necessary to revisit the code soon (especially the FIXME related to register IDs).
Another problem is that there is no generalization of register IDs. Thus, all experiments are currently specific to a concrete architecture (which is not desired).
git-svn-id: https://www4.informatik.uni-erlangen.de/i4svn/danceos/trunk/devel/fail@2010 8c4709b5-6ec9-48aa-a5cd-a96041d1645a
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
detectCPU() allows us to easily retrieve the current Fail-CPU object which is a regular use case in the aspect headers, now. (Another solution would be a slice in the Bochs CPU class which inserts a reference to the Fail CPU object. Maybe we 'll implement this at a later point.)
git-svn-id: https://www4.informatik.uni-erlangen.de/i4svn/danceos/trunk/devel/fail@2006 8c4709b5-6ec9-48aa-a5cd-a96041d1645a
