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
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
- Import timing information from traces that were recorded with timing.
- Allow restricting import to a memory map ("vertical" restriction).
- Proper fault-space right-margin handling.
- Cleanups, data-type usage, etc.
Change-Id: I7a49e8e9e49894c458e884bfc234f36b9ba8b130
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
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
