OTAWA  2.0
Framework to perform machine analysis and compute WCET.

This page provide documentation about the commands provided by OTAWA: More...

This page provide documentation about the commands provided by OTAWA:

dumpcfg Command

This command is used to output the CFG of a binary program using different kind of output.

> dumpcfg options binary_file functions1 function2 ...
dumpcfg first loads the binary file then compute and display the CFG of the functions whose name is given. If there is no function, the main functions is dumped.

Currently, dumpcfg provides the following outputs:

dumpcfg accepts other options like:

opcg Command

opcg is a simple OTAWA tool to display the Program Call Graph (PCG) of a binary program.

$ opcg [options] binary_file [entry function]

This program output in postscript the PCG of a binary program rooted by the given function or, as a default, by the "main" function.

The output file use the entry function name where the file type extension is appended. If you do not select a special file output and no entry function, the output file is named "main.ps".

The options includes:

-o|–output path – path of the file to output to.

-S|–statistics – display statistics about each subprogram.

-T|–out-type @i type – select the type of output (the @i type may be one of ps, pdf, png, gif, jpg, svg, dot, view).

ostat Command

OStat displays some statistics - average, maximum - about a binary file:

$ ostat binary_file function1 function2 ...

OStat displays statistics about the given binary file for the requested functions. If no function is provided, the main() function is used.

Options consists of :

$ ostat crc
BB count = 4
type = total count, average/bb, max/bb, ratio
instructions = 56, 14, 27, 100%
memory instructions = 20, 5, 9, 35.7143%
branch instructions = 4, 1, 1, 7.14286%

owcet Command

owcet command allows to compute WCET of an application using a script provided for a particular architecture implementation. It provide full power of OTAWA framework including selection of architecture-dependent plugin and fine-tuned computation scripts.


The @i EXECUTABLE_PATH must be the path of the executable file to compute WCET for. This executable file must be in a machine language understood by OTAWA (currently OTAWA supports PowerPC, ARM, Sparc, HCS12 and partly TriCore).

The optional @i TASK_ENTRY designs the function to compute the WCET for and usually matches a task in the real-time applications. If this parameter is not given, the @tt main function is used.

The @i SCRIPT_PATH is the path of the file containing the script. These file are usually found in $OTAWA_HOME/share/Otawa/scripts. When an architecture plugin is installed, it provides usually its own script.

Other options includes:


Real-time systems do not usually perform formatted output as @tt printf family of functions but such a function are often used in case of error. Usually formatting performed by @tt printf is big and complex piece of code that, in the case we take it into account in the WCET computation, would dominate the execution time and drive to a very overestimated WCET. To avoid this, you can command to OTAWA to ignore them without recompiling your application. Just create a file named YOU_EXECUTABLE.ff and write inside:

nocall "printf";

You can do the like with any function disturbing your computation. You can find in F4 : Flow Facts File Format more details about the commande @tt .ff files. You may also use XML format called @tt .ffx (see Flow Fact XML format).

mkff Command

This command is used to generate F4 file template file template (usually suffixed by a .ff) to pass flow facts to OTAWA. Currently, only constant loop bounds are supported as flow facts. Look the F4 : Flow Facts File Format documentation for more details.

$ mkff binary_file function1 function2 ...

mkff builds the .ff loop statements for each function calling sub-tree for the given binary file. If no function name is given, only the main() function is processed.

The loop statement are indented according their depth in the context tree and displayed with the current syntax:

// Function function_name
loop loop1_address ?;
loop loop1_1_address ?;
loop loop_1_1_address ?;
loop loop2_address ?;

The "?" question marks must be replaced by the maximum loop bound in order to get valid .ff files. A good way to achieve this task is to use the dumpcfg Command command to get a graphical display of the CFG.

$ mkff fft1
// Function main
loop 0x100006c0 ?;
// Function fft1
loop 0x10000860 ?;
loop 0x10000920 ?;
loop 0x10000994 ?;
loop 0x10000a20 ?;
loop 0x10000bfc ?;
loop 0x10000d18 ?;
loop 0x10000dc0 ?;
// Function sin
loop 0x10000428 ?;
loop 0x1000045c ?;
loop 0x10000540 ?;
Other information

mkff has the ability to produce automatically other commands to handle problematic or exotic flow fact structures:

In very complex programs, it may be required to launch mkff several times.

As mkff may detect unsolved indirect branches (function pointer call or swicth-like statements, the first phase consist to fill this kind information and to relaunch mkff to scan unreachable parts of the program. Possibly, some parts may also be cut to tune the WCET computation.

As an example, we want to build the flow facts of the program xxx.

  1. generate a first version: {$ mkff xxx > xxx.ff},
  2. if required, fix the non-loop directives and removes the loop directives,
  3. generate a new version: {$ mkff xxx >> xxx.ff},
  4. while it remains unfixed non-loop, restart at step 2.

In the second phase, you must fix the loop directives, that is, to replace the question marks '?' by actual loop iteration bounds.

odisasm Command

ODisasm disassemble a binary program and display information provided by the instruction loader, that is,

This command is particularly useful when a loader is written. It allows to examine the information provided by the loader from the OTAWA run-time point of view and to find back possible errors.

$ odisasm binary_file function1 function2 ...

The following are provided:

$ odisasm -ktr loop1
01800248 lwz r0,12(r31)
read regs = r31
written regs = r0
0180024c cmpi 7,0,r0,99
kind = INT ALU
read regs = r0 xer
written regs = cr0
01800250 bc 4,29,-9
target =
read regs = cr0 ctr
written regs =
01800254 lwz r0,8(r31)
read regs = r31
written regs = r0
01800258 or r3,r0,r0
kind = INT ALU
read regs = r0 r0
written regs = r3
0180025c addi r11,r31,32
kind = INT ALU
read regs = r31
written regs = r11
01800260 lwz r0,4(r11)
read regs = r11
written regs = r0
01800264 mtspr lr,r0
kind = INTERN
read regs = r0
written regs = lr
01800268 lwz r31,-4(r11)
read regs = r11
written regs = r31

odfa Command

ODFA allows to launch data flow analysis in a stand-alone way and to display the results. For the time being, only the CLP analysis is supported but more will be added later.

$ odfa binary_file function1 function2 ...

The following options are provided:

otawa-config Command

This command provides useful information to compile an OTAWA application or a plugin.

> otawa-config [OPTIONS] MODULES...

The following options are available:

odec Command

This command is an helper to implement a new loader plugin. Program decoding is a complex and time-consuming task implemented by otawa::TextDecoder analyzer. It uses the decoding ability of the loader to follow execution paths of the program. Because of the complexity of this work, a lot of inconsistencies are silently ignored by the decoder but these issues could be good indications about something wrongly done by the implemented loader.

As it should to costly to support verbosity switch in the decoder, this command proceed as the decoder but provides as much information on the process impossible. This makes easier the understanding and the retrieval of an error from a loader.

int main(int argc, char *argv[])
Definition: config.cpp:500
const T & max(const T &x, const T &y)
StringInput read(const char *s)
Inst::kind_t kind
Definition: odisasm.cpp:113
const Type & type(void)
Definition: type.h:163
inst branch(uint_t to)
Definition: inst.h:162
@ BB
Definition: ipet_parser.cpp:141
Definition: inst.h:45
Definition: MemType.h:30
int count(const C &c, const P &p)
Development Note Letting the ToDo / ToDoList class visible in the header is clumsy.
Definition: ArrayStore.h:25
p::id< string > TASK_ENTRY
This property, passed to the load configuration, gives the name of the entry function of the current ...