Line 1... |
Line 1... |
Instruction analysis program
|
Instruction analysis program
|
|
|
This application reads in a binary list of instructions, and analyses it with a
|
This application reads in a binary list of instructions, and analyses it with a
|
set of functions looking at various parameters in each instruction.
|
set of functions looking at various parameters in each instruction.
|
|
|
It has been designed so a different instruction set support can be added.
|
|
|
|
Right now it's not so user friendly. Everything is hardcoded, and only support
|
Right now it's not so user friendly. Everything is hardcoded, and only support
|
for the OR1K instruction set exists.
|
for the OR1K instruction set exists.
|
|
|
|
It has been written in a way that should allow other instructinos to be added
|
|
easily. It remains to be seen how much would be reusable between the sets but
|
|
for now, at least it would be easy enough to take the OR1K instruction
|
|
analysis functions and drop in a different instruction set.
|
|
|
|
The types of information given for OR1K instruction analysis is instruction
|
|
frequency, immediate frequency for each instruction, branch distance value
|
|
frequency, and register usage frequency. For each instruction, the most common
|
|
n-tuple sets of instructions, finishing with that instruction, are presented,
|
|
for pairs, triples and quadruples. Additionally output is the most common
|
|
overall n-tuples.
|
|
|
Compile the program with:
|
Compile the program with:
|
|
|
$ make all
|
$ make all
|
|
|
And run a test (it needs the or32-elf- toolchain) with:
|
And run a test (it needs the or32-elf- toolchain) with:
|
Line 17... |
Line 27... |
$ make test
|
$ make test
|
|
|
To run the program itself, just give it a binary blob of instructions (usually
|
To run the program itself, just give it a binary blob of instructions (usually
|
the output of objcopy -O binary).
|
the output of objcopy -O binary).
|
|
|
For instance the Linux kernel ELF can be prepared with the following command:
|
Static analysis:
|
|
|
|
For instance the Linux kernel ELF for OR1K can be prepared with the following
|
|
command:
|
|
|
$ or32-elf-objcopy -O binary -j .text -S vmlinux vmlinux.text.bin
|
$ or32-elf-objcopy -O binary -j .text -S vmlinux vmlinux.text.bin
|
|
|
Run it in the program with
|
It is passed to the program like so, and the output is captured by redirecting
|
|
stdout.
|
|
|
$ ./insnanalysis vmlinux.text.bin > vmlinux.insnanalysis
|
$ ./insnanalysis vmlinux.text.bin > vmlinux.insnanalysis
|
|
|
Currently the program will output all appropriate information for each
|
Dynamic analysis with binary execution log from or1ksim:
|
instruction (ie. only ones with rA, or immediate fields in the instructions will
|
|
have reports on those fields.)
|
As of revision 202 of the OpenRISC repository, or1ksim is capable of generating
|
|
an execution trace log in binary format, logging each instruction executed.
|
|
This log file can be given to insnanalysis.
|
|
|
|
In the or1ksim config file ensure the line "exe_bin_insn_log = 1" is in the
|
|
sim section. This will enable the binary instruction logging. The resulting
|
|
output file is then given to insnanalysis in the same manner as above.
|
|
|
|
Output:
|
|
|
|
Currently there are only two output formats, human readable string and CSV.
|
|
|
|
The output can be switched between human readable strings and CSV format (ready
|
|
to be imported into a spreadsheet application) by uncommenting one of the
|
|
"#define DISPLAY_" defines in the instruction set header. The program must be
|
|
recompiled if this is changed.
|
|
|
|
|
TODO:
|
TODO:
|
|
o Collect and display information about l.j and l.jal instruction immediates
|
o Add an easy way to switch between human readable and CSV output
|
o Add an easy way to switch between human readable and CSV output
|
o Figure out how to tack this thing onto a simulator (or1ksim maybe) to give
|
o Figure out how to tack this thing onto a simulator (or1ksim maybe) to give
|
results of execution when that finishes executing, or just how to get the
|
results of execution when that finishes executing, or just how to get the
|
simulator to output a binary dump of executed instructions to be fed through
|
simulator to output a binary dump of executed instructions to be fed through
|
this
|
this
|
|
o Add support for a list of binary files to be specified at the command line
|
|
o Allow statistics to be collated over different files - this would allow each
|
|
function to be broken out of a library, or application, and in that regard
|
|
the instruction sequence data would then be accurate for static analysis.
|
|
|
|
|
|
July 24, 2010 - Julius Baxter
|