The Fail* tools expect trace events to be ordered in a specific way:
memory-access events are supposed to come *after* the instruction
event for the instruction that caused them. Using a different order
may cause subtle problems with both fault-space pruning and fast
forwarding. This change introduces a warning message when such a
malformed trace is detected (i.e., when the instruction pointer of a
memory-access event does not match the preceding instruction event).
Change-Id: I8ae7420fd8ff26e2574590748bdcc5a63db76490
Richard noticed that instr2 values are off by one when done with the
MemoryImporter vs. with his own importer. The core problem is that
the dynamic instruction counter in the Importer base class
(Importer::copy_to_database, instruction_count_t instr) gets increased
*after* reporting an IP event to the importer implementation; this has
the side-effect that memory access events have a +1 dynamic
instruction count offset with regard to the IP event of the
instruction they belong to.
Bottom line: IP events and all memory events belonging to that
instruction should have the same dynamic instruction number.
Christian argued for the numbers starting with 0, which, as a side
effect, relativizes the repercussions of the change introduced in the
previous commit, as the new "first" event gets the sequence number 0
now.
- All experiments and importers only dealing with memory accesses
(MemoryImporter) are affected by this change: The dynamic
instruction count now starts with 0 instead of 1. Together with
the previous commit, the only change is one additional dynamic
instruction at position 0. Note that existing trace files do not
have this additional instruction, which shifts all trace positions
by 1.
- All importers that process *only* IP events (InstructionImporter,
RandomJumpImporter, RegisterImporter) won't see any difference.
Commit 036e340, though, introduced a +1 offset.
- Experiments that use these instruction counts for navigating to
the target instruction must be checked to properly deal with the
dynamic instruction #0 (no forwarding necessary). All dynamic
instruction offsetting should now work uniformly for both memory
accesses and all other fault models. To be sure everything works
in order, sanity-check the current absolute instruction pointer
right before fault injection.
Change-Id: I3f509f1b47836fa78fd029a7bb7c36c878912d97
If you only need raw failure counts, no-effect write equivalence classes
are redundant and only slow down access to the trace and fspgroup tables.
This switch prevents any accesstype='W' entries from finding their way into
the trace table.
Change-Id: Ifb415994063a2107769bc80ebd2fd780de5a4dda
Initially this was implemented by directly passing through trace
events to the MemoryImporter, keeping a record of conditional jumps
and opcodes, and UPDATEing all inserted rows in a second pass when the
MemoryImporter is finished.
Unfortunately, UPDATE is very slow, and keeping all information in
memory till the end doesn't scale indefinitely. Therefore the
implementation now delays passing memory access events upwards to the
MemoryImporter only until enough branch history is aggregated, and
taps into Importer's database operations with a set of new virtual
functions that are called downwards.
Change-Id: I159b2533932087087fb3049f4ff07a5f17a25a00
A MemoryImporter that additionally imports Relyzer-style conditional
branch history, instruction opcodes, and a virtual
duration=time2-time1+1 column (MariaDB 5.2+ only) for fault-space
pruning purposes.
Change-Id: I6764a26fa8aae21655be44134b88fdee85e67ff6
This change touches several subsystems, tools and experiments
(sal, util, cmake, import-trace, generic-tracing, nanojpeg), and
changes details not worth separate commits.
Change-Id: Icd1d664d1be5cfc2212dbf77801c271183214d08
This tool can now import extended trace information with the
--extended-trace command-line parameter. The existing importers cease
using artificial access_info_t objects in favor of passing through the
original Trace_Event wherever possible. This allows us to import
extended trace information for all importers.
Change-Id: I3613e9d05d5e69ad49e96f4dc5ba0b1c4ef95a11
data_address is definitely part of the unique key to trace entries, but
instr2 is arbitrary (could be instr1, time1 or time2 as well). Moving
data_address up the hierarchy to speed up certain FSP experiments.
Change-Id: I37a1f6c1e5b3957ba2f5bf46e0cd1a9c4aa7bfef
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
We need to cover the complete fault space when a memory map is
provided. This means fake trace entries for completely unaccessed
addresses (e.g., unused parts of the stack), and makes sure we include
all of our fault space in the statistics later.
Without a memory map, we just don't know the extents of our fault
space; just guessing by using the minimum and maximum addresses is not
a good idea, we might have large holes in the fault space.
Change-Id: Ieb4b30a2e41a9921b969bf88513bfbacfc290c93
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
- 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
