With the recent updates to record one additional instruction at the trace
start, I broke memory-map handling (restrictMemoryAddresses() and
restrictInstructionAddresses()). This change repairs this functionality.
Change-Id: I0daf9f474d0efe3f8e30a168c0ccc1e993e7ddc6
Listens on a configurable SUT's global variable.
On read access a signal pattern value is calculated and sent back
to the SUT.
Currently, only a superimposable sine wave signal form is implemented.
Further signal forms can be implemented by inheriting from the
abstract SignalForm class.
Change-Id: I2e6cf49cd44797999691c9e9cf0c54dd3c96875e
Logs access to a given global variable of the SUT, given by
a symbol name, and outputs value when variable is written to file.
Format:
<Simulation time>;<Value of variable>
Change-Id: I81b581e571be4255a1a2200c41e7c16657ddfd3d
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 internal m_iponly / m_memonly bools are a bit hackish; especially it's
unclear what should happen if both are set. The m_tracetype enum now
encompasses all possible configurations, while the plugin's user interface
remains unchanged.
Change-Id: Ibdd872b5cc5781836428b27bfb2db3825700e671
This change implements what the source-code comment already promised but
didn't keep: As we only record time deltas instead of absolute time values,
prevtime must not be overwritten unless the current delta was really added
to the trace. This has caused timing information to be stored incorrectly
if certain events were skipped (e.g., because they didn't match the memory
map configured by the user).
Change-Id: Id40271d117dd91b1122136c62329d64174f304b0
When starting the tracing plugin (simulator.addFlow()), at the moment
the *current* dynamic instruction (e.g., the one the start symbol
points to) is skipped, and tracing commences with the second
instruction. This change records an additional instruction event at
the trace begin.
Note that this change affects all tracing-plugin users. The first
event gets recorded when starting the plugin (simulator.addFlow()).
This avoids compatibility/off-by-one issues when recording traces with
the generic-tracing experiment vs. with custom experiments.
Change-Id: Ic24e17a68b8a44edad3be994e9edd6d6712bfda1
This reverts commit 036e340bd9.
Problems with this one were:
- Broken event timings. m_prevtime wasn't reset to m_curtime in
TracingPlugin::handleSingleIP(), resulting in a large deltatime
being recorded for the second event, too. This effectively
doubled the experiment's start time.
- Code repetition (copy/pasted for special handling of first event),
making planned changes (advanced tracing for IP events) more
difficult.
- Unnecessary additional tracing-plugin interface method.
Change-Id: I4b74d1a3f4563aabe6626399f9b30a2171b4c285
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 extended trace register list is needed in multiple locations; the CPU
class is the logical module to contain this information.
Increased number of x86 registers to be traced; we can remove those
that prove unusable for fault-space pruning later on.
Change-Id: Ic46ecdbc55167a6d92872c190317fc0d1a3ad92d
When recording a "full" trace (register values, plus dereferenced
values), we use a fixed dereference size of 4 bytes.
Change-Id: Ifbf6730377e7df2e7f1fc1e6b91bc114ccf10fbc
This adds an interface for a backend-specific notion of time, e.g. CPU
cycles since simulator start, and a concrete implementation for the
Bochs backend. This is needed to record CPU idle times (e.g., HLT
instruction), and for target backends capable of more timing-accurate
execution.
This change also modifies the tracing plugin to add the time to all
trace events.
Change-Id: I93ac1d54c07f32b0b8f84f333417741d8e9c8288
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 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
This is a precaution to avoid current and future naming conflicts with
common system libraries. libutil (part of libc) is the first, but probably
not the last example that already caused trouble twice.
git-svn-id: https://www4.informatik.uni-erlangen.de/i4svn/danceos/trunk/devel/fail@1614 8c4709b5-6ec9-48aa-a5cd-a96041d1645a
