WET Home

First, the WET infrastructure must be set up according to the installation instructions. Once that is complete, WET can be run by following the directions below.

This is an optional step that uses Diablo to gather static control dependence information if dynamic control dependence information is desired in the collected traces. Diablo must be installed to perform this step. To gather the static control dependence information, first set the environment variable "TOOLCHAIN" to refer to the "gcc" executable for the patched gcc tool chain. Then set the environment variable "DIABLO" to refer to the installed Diablo executable. Next, execute the following commands (assume "foo.c" is the program to analyze and "foo" is the corresponding executable):

mkdir cd
gcc -c -g foo.c
$TOOLCHAIN -o foo -static -Wl,-Map,foo.map foo.o
$DIABLO foo

This will create and populate a directory named "cd" that contains static control dependence information of the target program to be later used when collecting tracing information for a particular execution.

To collect tracing information in either of the two possible formats, first initialize the environment variable "VALGRIND" to refer to the Valgrind executable.

To collect comprehensive tracing information for the execution of a program, execute the following command (assume "foo 2 7" is the command to execute the program):

$VALGRIND --tool=lackey --optimise=no foo 2 7

To collect dynamic dependences for a limited execution history, execute the following command (assume "foo 2 7" is the command to execute the program):

$VALGRIND --tool=lackey --optimise=no --bufout foo 2 7

For either type of tracing information, WET will output the collected information in the appropriate format to the file named "TRACE.txt".

To perform online backward dynamic slicing from within Valgrind, the instruction instance from which to start slicing must be specified as a command-line flag to Valgrind. This flag should be specified in the form "--slice=INSTRUCTION_INSTANCE", where "INSTRUCTION" is the instruction address and "INSTANCE" is the corresponding instance number from which to start slicing. This can be done the same regardless of whether tracing information is collected in the comprehensive or limited formats.

For example, to perform online slicing while tracing in the comprehensive format, execute the following command (assume "foo 2 7" is the command to execute the program, and instruction "0x8048EB8", instance "2" is the instruction instance from which to start slicing):

$VALGRIND --tool=lackey --optimise=no --slice=0x8048EB8_2 foo 2 7

To do the same while tracing in the limited format, execute the following command:

$VALGRIND --tool=lackey --optimise=no --bufout --slice=0x8048EB8_2 foo 2 7

In either of the above two cases, WET will output the computed slice in the file named "SLICE.txt", and the tracing information in the file named "TRACE.txt".

By default, WET will output the tracing information in addition to outputting the slice. To prevent this, the Valgrind command-line flag "--noout" will prevent the tracing information from being outputted. The above two examples can be changed as follows to output only the computed slice:

$VALGRIND --tool=lackey --optimise=no --noout --slice=0x8048EB8_2 foo 2 7
$VALGRIND --tool=lackey --optimise=no --bufout --noout --slice=0x8048EB8_2 foo 2 7

To support recording/replaying multithreaded program executions, the new command-line options "--record" and "--replay" are now provided in this release. The "--record" option specifies that the scheduling decisions of an executing program need to be recorded and logged to a file.

$VALGRIND --tool=lackey --optimise=no --record foo 2 7

During this recording execution, Valgrind dumps every scheduling event into a file named "logtrace.txt". Each event contains five elements, namely: threadID, startPC, startInstance, nextPC, and nextInstance. For example, a scheduling event

2 804857B 2 80485CC 1

means that thread 2 was scheduled to start at the second execution of instruction 0x804857B, and descheduled before the first instance of instruction 0x80485CC.

If "--replay" is specified, the Valgrind scheduler reads scheduling events in "logtrace.txt" and makes the scheduling decisions based on the logged events.

$VALGRIND --tool=lackey --optimise=no --replay foo 2 7

*Note that during replay mode, the input has to be the same as it was in the recording run. Also, the current release does not record/replay I/O events, only scheduling events.