Improved handling of optimization binaries in conjunction with automatic annotation extraction from the Data Dictionary.
AIS2 now officially replaces AIS1.
The second revision of the AIS annotation language comes with many new features and is much more user-friendly. For backwards compatibility, AIS1 specifications are still supported and included in the appendix of the user manual.
We strongly recommend upgrading your analysis specifications to the new AIS2 format.
Key improvements and new features are explained in the notes for release 15.04 and 15.10. New features in this release are as follows.
collect initialization: "msg_length", "can_msg_buffer";
assert assembly
annotation
now supports regular expressions:
ais2 { instruction <pp> assert assembly: match("bkpt #[34]"); }
# unroll loops 16 times for non-stack analyses if (!analysisType("stack_analysis")) { mapping default unroll: 16; }
enter with
annotations for calls
between two routines. This is helpful when the value annotation
depends on the calling context which cannot be easily expressed
with a routine-specific enter annotation:
ais2 { routine "handleInput" calls to "memcpy" { enter with: reg("r5") = 80; } routine "handleOutput" calls to "memcpy" { enter with: reg("r5") = 40; } }
infeasible call stack
annotation:
# specify that QuickSort cannot be reached from f->QuickSort->QuickSort routine "QuickSort" { infeasible call stack: "f", "QuickSort", "QuickSort"; }
ais2 { area 0x0 to 0xffff, 0x40000000, 0x4000fff { count accesses; } }This instructs the analysis to count accesses to either
0x0..0xffff
or 0x40000000..0x4000ffff
on the WCET path.class BaseButton { public: virtual ~BaseButton () { } public: virtual void clicked () = 0; }; class SingleButton : public BaseButton { public: void clicked () { // do something } }; class SingleButtonWithIcon : public SingleButton { public: void clicked () { // do something else } }; void handleButton (class BaseButton *button) { button->clicked (); }
The compiler cannot statically determine which member function
is going to be called when executing the function handleButton
.
Instead it generates code to look up the correct member function
based on the virtual function table of the corresponding object instance.
You can use the following annotation to enable the decoder to resolve the computed call:
instruction "handleButton" -> computed (1) calls: "BaseButton"::"clicked";
The decoder will then resolve the call to the
member function implementations SingleButton::clicked
and SingleButtonWithIcon::clicked
.
The complex area definition now offers the attribute
skipped: type;
for checking whether
the pointer target has the expected type. The attribute
is similar to the skipped: null;
attribute.
Consider the following C snippet:
typedef void (*fPtr) (int); void f (int x) { ... } void g (int x) { ... } struct fEntry { fPtr x; int y; }; struct fEntryLarge { fPtr x; int y; int z; }; const struct fEntry a = { &f, 3 }; const struct fEntryLarge b = { &g, 5, 12 }; const struct fEntry *fTable[2] = { &a, &b };
The complex area definition
("fTable"[]->"f"->)
would evaluate to the addresses of the routines f
and g
. However, according to the declaration
of fTable
, it should only contain pointers
to structures of type fEntry
. Nonetheless,
C compilers often allow the above code even though
a
and b
are in fact incompatible types.
In order to check whether resolved addresses refer to objects of expected type, you can now use the following definition:
("fTable"[]-> { skipped: type; } "f"->)
Using debug information, the decoder only resolves
the address of f
and ignores the second table
entry of fTable
. In this case, it will report:
Discarded pointer targets with unexpected type.
Expected type ‘const struct fEntry’, but found ‘const struct fEntryLarge’ at 0x4005f0.
exec2crl: Fatal: Compiler is ambiguous, please use a compiler annotation to specify the matching one. Possible compilers are: 'Greenhills C compiler' (ppc-greenhills), 'Greenhills Ada compiler' (ppc-greenhills-ada)
sdiv
and udiv
bfc
and bfi
StackAnalyzer can now be run in context-sensitive mode, allowing the analysis to rule out transitions that are infeasible in the context-sensitive call graph.
This is especially useful for deeply nested call stacks, where context-sensitive analysis gets much more precise results.
The GUI now offers three analysis modes:
Context-sensitive analysis is the default, as it is the most precise.
#3081: Propagating a non-zero system stack effect for loop 'task_handler_1ms.L1'. Current relative system stack height is [64..128] bytes.
rlwinm
x <> x + y
(x % 2) == 0
code patterns*** *** Maximum stack usage for entrypoint 'main' *** Maximum global usage: 96 bytes of stack => Callstack for maximum global usage: -> 0 < 48> 'main' -> 48 < 12> 'fib' -> 60 < 12> 'fib' -> 72 < 12> 'fib' -> 84 < 12> 'fib' => 96 bytes of stack Applied incarnation limits: => Routine 'fib': 0: main -> 1: fib -> 2: fib -> 3: fib -> 4: fib -> 5: fib <= infeasible because of exceeded limit
eva-microblaze: Warning #3075: In "minmax.c", line 17:
In routine 'max', at address 0x20c:
In context '0x2bc->"max"':
Write access related to stack pointer 'r1' to [0x000004df]:4, which overlaps with read-only memory.
eva-hcs12: Info: Local default-unroll settings for loops:
* Loop 'main.L1' default-unroll = 256 ('stack modification' heuristic)
* Loop 'main.L1' default-unroll = 10 (annotation)
* Loop 'CASE_SEARCH_8.L1' default-unroll = 256 ('switch table' heuristic)
rlwinm
instructionmuls
/muls.u
instructions.tw
and twi
instructions, which are now handled as computed calls
and executed as integer instructions.Cumulative WCET computation has been improved and is now feasible in more cases.
exec2crl: Info: Reading binary 'edn.elf'.
* Type: ELF
* Size: 519 KB (532246 bytes)
* MD5: f9edb23a7168d993451073fabdbab1fa
eva-ppc: error #3076: in "test.c":
In routine 'test2.L2', at address 0x4594:
In context '0x4938->"test1", 0x4710->"test2", 0x4578->"test2.L1"[2..]':
User annotated loop bound of [8] contradicts computed loop bound of [1].
Annotating a loop bound of [0], which may lead to an incorrect analysis result.