You can not select more than 25 topics
Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
23 lines
1.4 KiB
23 lines
1.4 KiB
# Tracing
|
|
|
|
We use a pintool to trace all crashing and non-crashing inputs.
|
|
|
|
|
|
## Setup
|
|
1. Install Intel Pin in version 3.15 (note, the original pintool was designed for 3.7 - which is no longer available for download, such that we have updated the pintool to version 3.15).
|
|
|
|
2. Set PIN_ROOT to point to the correct location, e.g., `export PIN_ROOT=/home/user/builds/pin-3.7-97619-g0d0c92f4f-gcc-linux/`.
|
|
|
|
3. Run `make aurora_tracer.test` or ` make obj-intel64/aurora_tracer.so` to build the pintool.
|
|
|
|
## Usage
|
|
|
|
In scripts, you can find an example script `run_tracer.sh` on how to run the tracer. In general, tracing will generate an output containing the trace as JSON and a logfile. Note that Pin struggles with long paths for both output file and logfile.
|
|
|
|
The second script, pprint.py, allows to pretty-print the trace file.
|
|
|
|
`tracing.py` requires at least Python 3.6 and allows to trace multiple files (and zips them for space reasons - root cause analysis tooling can deal with zipped traces automatically) and expects PIN_ROOT to be set. It requires 3 arguments: the path to the (non-AFL instrumented) trace binary, an input folder where `crashes` and `non_crashes`can be found as well as an output folder where to drop the `traces. A tracing.log logfile is created.
|
|
|
|
The fourth script, `addr_ranges.py` extracts heap and stack address ranges from logfiles generated by `tracing.py`.
|
|
|