If the --debug option is set, the line number table of the elf binary will
be imported into the database. The information will be stored in the
"dbg_mapping" table.
If the --sources option is set, the source files will be imported
into the database. Only the files that were actually used in the
elf binary will be imported.
Change-Id: I0e9de6b456bc42b329c1700c25e5839d9552cdbb
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
As non-gzipped trace files cause import-trace to always import zero
events, the input file is now openend as in the dump-trace tool, where
opening non-gzipped files obviously works fine.
In the medium term we should find a centralized solution for this,
instead of re-implementing it all over the place.
Change-Id: I75845c03c0bbdc2b6b578b83d492b7dbbb40f051
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
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
Without this change, import-trace won't recognize, e.g., the -e and -t
parameters if they come after a parameter that was added by the Importer:
import-trace -i objdump --objdump arm-none-eabi-objdump -e B.elf -t C.tc
[...]
[import-trace 14:37:32] couldn't open trace.pb
Change-Id: I9532b01e432055479c79d801b1ca2736a8fd21cc
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
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
It's OK if we cannot map every register LLVM knows to a Fail register
ID, but we need to explicitly skip these cases in the
RegisterImporter.
Change-Id: I2152f819fb94aa4de5720c5798b229b66988d382
Contemporary AspectC++ versions can deal with the LLVM headers very
well, and #ifdef __puma stuff in Fail* headers results in
unmaintainable #ifdef __puma blocks in other parts of Fail* (e.g., the
trace importer).
Make sure you're using a 64-bit ac++ when living in a 64-bit userland
(the 32-bit version doesn't know about __int128), and be aware that
AspectC++ r325 introduced a regression that has not been fixed yet.
Change-Id: I5bb759b08995a74b020d44a2b40e9d7a6e18111c
For def/use pruning, the linear address mapping of the x86
sub-registers (e.g., AX represents the lower 16 bits of EAX) must
overlap. If it doesn't, e.g., AX and EAX are considered separate
registers by def/use pruning, resulting in a failure to correlate an
EAX def with a subsequent AX use.
The only user of this mapping up to now, RegisterImporter, forced all
register widths to 8 bits, thereby fortunately canceling out this
problem. Nevertheless it makes no sense to continue encoding a
constant width in these virtual addresses.
Existing trace, fspgroup, fsppilot and result tables may be converted
to the new encoding by using this query:
UPDATE <tablename> SET data_address = ((data_address >> 4) & ~0xf) | data_address & 0xf;
Change-Id: I7a942b78c34f6140803a86af639eeedef3550f34
This change introduces a CMake-style FindMySQL.cmake properly looking for
libmysqlclient_r with mysql_config. This also fixes linking on some
machines.
Change-Id: Ifdbfdc3c7440dead37a8b63aaa86732d636aa0e2
This was necessary because LLVM 3.1's
ELFObjectFile<ELFT>::sectionContainsSymbolsectionContainsSymbol() (needed
for proper functioning of our LLVM disassembler, unless you're using
-ffunction-sections) is "unimplemented".
Change-Id: I81112627ebd1c92b718ac6f4ed58d7f188aedf0c
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
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
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
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 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 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
