The configure step for libfailbochs_external could be executed parallel
to other build steps, which required the files produced by the configure
step. Therefore a race-condition occurred. By giving the configure step
an explicit target name, more correct dependencies could be modeled
within bochs.cmake.
Change-Id: If2d7dafdace23b0eba6efcdff3ed0bfca2423048
Instead of issuing a query for every variant, we assemble a set of
variant ids and query `WHERE variant_id in (1,...)'. This has not only
the effect of higher optimization potential for the database, but also
the query is issued before any result can come back. This will avoid an
overfull receive queue within the job server.
Change-Id: I5b1c60f92b97741ce26d9e50760b601929cef44f
assert(...) can be optimized away, therefore side-effect code should not
be placed inside an assertion.
Change-Id: I28aee42e53cb105333094d0042a3f6e2cc5b5a30
Since we know for which variant we want to have the completed pilots, we
do not have to catch all pilot_ids but only those who of pilots that are
finished and have the correct variant_id. This speeds the startup of the
campaign server enormously when having many completed campaigns in the
database.
Change-Id: I8be584a2dd6d8d7315f30dcb5bff89647353001e
There are instruction in the real world, that seem to read more than 8 bytes.
Therefore we cap the accesses memory to 8 and don't abort with an assertion.
Change-Id: Ib2bfd0ac6dc0c030cd6a22940e31f8463a3337cf
Differences:
- the task activation order is determined in the faulty experiment as
well as in the golden run (which is now done by
fail-generic-tracing) by observing a variable fail_virtual_port.
- There is a panic value read from the fail_virtual_port
- The golden run task activation is determined by giving an extended
trace to task_activation.py. The script collects all writes to
fail_virtual_port, and determines the activation from this.
Change-Id: Id401b78933b45a4b2cf031fc0a8b5ac90151ec24
When a register in the extended trace was dereferenced and the value
was smaller than the memory pool size, but the address was not mapped
an assertion occured and the tracing plugin terminated the
simulator. Now the dereferenced memory address is checked for being
mapped and not being smaller than the memory pool.
Change-Id: I9ac954988ef860969679f9f360814c5e4b66f473
The ElfImporter is not a real trace importer, but we locate it
into the import-trace utility, since here the infrastructure is
already in place to import things related to an elf binary into
the database.
The ElfImporter calls objdump and dissassembles an elf binary
and imports the results into the database.
Change-Id: I6e35673c8dbee3b7e8dfc7549d10e5dca9b55935
When using the generic-tracing experiment for generating a trace, the
first event, after the tracing is started (the start-symbol) is lost
in the trace. This patch handles this special case seperately.
Change-Id: Ia131a8559d67161532504160826fdb100247ed75
The experiment does support
- 1 bit faults in registers/memory/IP
- 2 bit faults in registers (all)
- n bit faults monte-carlo in registers
Change-Id: Ifdd7df6ec4bc88cfc75391b5e19e0d648fd0d087
The RegisterImporter splits each register into 1 byte chunks. The
--do-not-split flag prohibits this splitting. Be aware, that def/use
pruning won't work correctly in mixed-width cases (EAX/AX/AH/AL).
Change-Id: Ifa1930bdd9f317a6fd3ae50c4ff3cffc97504640
During the prune step the data_width of the injected location was not
propagated before. It is now stored in fsppilot (database layout change!) and
sent in the fsppilot protobuf message.
Change-Id: I0562f6fc8957adea0f8a9fb63469ca5e3f4b7b2d
The random jump importer defines trace events, that indicate all
possible jumps into a specific instruction range. The region where
jumps should start can be defined by a memory map given with
--jump-from. For each instruction declared in that memory range, all
possible jumps to a memory region specified by with --jump-to are
inserted. The target of the jump is saved in the data_address
field. So all database tools work as expected.
for each event E \in region(--jump-from):
foreach Instruction in region(--jump-to):
insert_trace(injection_instr = E.IP(), data_address = Instruction.addr)
Change-Id: Ie163968acae47fc6c946fc77774c47ee07950bab
The RegisterImporter disassembles the binary and adds a trace event
for each byte read or written from register. The register number (Fail
Register Numbers are used) and the offset within the register are
encoded within the trace event.
Change-Id: I2d2fd720841fedeeff5f28b64f24ec5f6d2ea0c3
The InstructionImporter does disassemble the binary and generate read
traces for every instruction byte executed.
Change-Id: I6b8697c711c009e106ed733c74c6ff8f9bbf8ac5
The variant/benchmark selection now can use SQL LIKE syntax, all unfinished
pilots from all selected variants are sent to the clients. E.g.:
./cored-voter-server -v x86-cored-voter -b simple-% -p basic
Will select the fsppilots in the variants:
- x86-cored-voter/simple-ip/basic
- x86-cored-voter/simple-instr/basic
The variant and benchmark information is now sent within the
fsppilot.
Change-Id: I287bfcddc478d0b79d89e156d6f5bf8188674532
The LLVM Disassembler infrastructure can be used to analyze many kinds
of ELF Binaries. For every instruction the used and defined registers
is available as well as information about the instruction itself.
Change-Id: I9cc89b6c116ceff7b5143a6f179ae31c4e994d2d
This does enable % patterns in variant and benchmark selections, like
it is already implemented in the prune-tool.
Change-Id: I7497bfd588d6ffdf851d767bafc660f4872ae92f
BasicImporter is renamed to MemoryImporter. An alias for BasicImporter
in the cmdline interface will remain. The MemoryImporter does now only
handle memory and IP events. The simulation time, dynamic instruction
count and handling of open ECs is moved to Importer.
Change-Id: I04eb0fd4b52fbf5b0ca9ab97778a62130cb626ee
This importer is so similar to the basic importer, that it can be
dropped. The current state was used in the SOBRES 2013 Paper.
Change-Id: Ibed1af6e1a72286500d42e83e594557d6dcf3803
The correct flags accessor methods should be used to write the flags register,
since values (especially the arithmetic flags) might be cached.
Change-Id: I338927cfdd1f111966be539668914c9256b54c8f
The previous fault injection experiment was kind of bullshit. This one
is better in several ways:
- sanity check at injection time (correct IP)
- correct counting of kernel_transistions
- copy whole activation scheme
Change-Id: I014eea4d6fe103bc02ffd7bbca95dc56a1a4d9ea
Is now very similar to normal importer, and may be deleted in the future, but
at the moment, this should be merged, since it is the importer used in the
sobres-2013 paper.
This changes the MySQL Schema. instr1_absolute was introduced.
Change-Id: I1bc2919bd14c335beca6d586b7cc0f80767ad7d5
The dciao-kernelstructs experiment does a trace imported by the
DCiAOKernelImporter:
bin/import-trace -t trace.pb -i DCiAOKernelImporter --elf-file app.elf
Pruned by the basic method:
bin/prune-trace
and does CiAO fault injection experiments, where the results are
stored in the database.
Change-Id: I485dc2e5097b3ebaf354241f474ee3d317213707
The wrapper builds a temporary bochsrc and sets an FAIL_STATEDIR
environment variable to a temporary directory. FAIL_ELF_PATH is also
set in regard to the command line interface.
Change-Id: I647c6eb3a91ae22847958ca30ede6e09519fba04
The DatabaseCampaign interacts with the MySQL tables that are created
by the import-trace and prune-trace tools. It does offer all
unfinished experiment pilots from the database to the
fail-clients. Those clients send back a (by the experiment) defined
protobuf message as a result. The custom protobuf message does have to
need the form:
import "DatabaseCampaignMessage.proto";
message ExperimentMsg {
required DatabaseCampaignMessage fsppilot = 1;
repeated group Result = 2 {
// custom fields
required int32 bitoffset = 1;
optional int32 result = 2;
}
}
The DatabaseCampaignMessage is the pilot identifier from the
database. For each of the repeated result entries a row in a table is
allocated. The structure of this table is constructed (by protobuf
reflection) from the description of the message. Each field in the
Result group becomes a column in the result table. For the given
example it would be:
CREATE TABLE result_ExperimentMessage(
pilot_id INT,
bitoffset INT NOT NULL,
result INT,
PRIMARY_KEY(pilot_id)
)
Change-Id: I28fb5488e739d4098b823b42426c5760331027f8
This tool creates the fault-space pruning pilot and group
entries. Those are used by the generic campaign to do fault
experiments.
Currently prune-trace only implements conventional def/use pruning
(--prune-method "basic").
Change-Id: I1dfb431e3b1d3cd2ee891a49a3b6ac01210be11f
The import tool does support the following import strategies:
- BasicImporter: generates def-use equivalence classes for read and
write memory accesses
- DCiAOKernelImporter: generates equivalence classes for read access in
the ciao kernel space.
Change-Id: I8960561d3e14dcf5dffa3ff7a59b61a5e8f7e719
The full-tracing plugin was used in the DSN paper. It additionally
traces the data that was accessed/written on a memory access and the
contents of some CPU registers.
Change-Id: I61f5230699009ce523aba341985b98148160556d
