The analysis speed and memory consumption have been improved by streamlining the analysis toolchain and reducing the number of required tool runs. Extreme speedups can now be achieved, especially on projects with a large main analysis and many smaller subanalyses.
qk_ais2_expression_pp_area
operators.REQ_
to better distinguish them from test case identifiers.The Linux version now requires the libxcb-*
family of libraries to be installed.
You can now simply press F1 to get context-sensitive help for the current screen, a selected keyword, or a highlighted message. The previously separate quick references for graphs and AIS are now integrated in this help as well.
In addition to packing the complete project as before, you can now choose to only pack the most recent analysis run. This is very fast, as no recomputations are needed.
The provided example projects have been improved to showcase more analysis features.
evaluated .. as
annotations._FuncTask
and FuncTask
as duplicated entries and choose one of them.# short global callstring mapping max length: 1; # longer local callstrings routine "Func2" { mapping max length: 2; } routine "Proc1" { mapping max length: inf; }
# local unrolling routine "fac" { mapping default unroll: 2; }
routine match("syscall_(.*)") { obeys calling conventions; stack "user" usage: 0 bytes; stack "system" usage: 64 bytes; }
static int dataTable[124];the number of entries in the array
dataTable
can be accessed as:
entries("dataTable")This can then be used, for example, to bound a loop that iterates over that array:
loop "processData.L1" bound: entries("dataTable");
Reading 4 bytes (0x204) at address 0x24a8 (variable 'arr[1]') from writable section '.data' to reconstruct the control flow.
You should manually verify the reconstructed control flow.
Potentially you might need to annotate branch/call targets.
Function-local static variables can now be addressed in AIS2 by means of DWARF debug information. To avoid conflicts with global variables, the name of the enclosing function is prefixed.
As and example, consider the following source code snippet:
void handle_msg (...) { static int buffer[128]; ... }
The local static variable buffer
can then be addressed via handle_msg::buffer
.
Loop <function.Lx> is specified in AIS as type 'end', but might rather be a 'begin' loop.
false
for new projects, true
for old ones.
When the option is disabled, all AIS files will be parsed as AIS2, allowing to use AIS2 annotations
freely without the ais2
scope and disabling the legacy AIS1 annotations.false
.Loop 'memcpy.L2': heuristic matches in all contexts with [2..17] iterations (loop is assumed to iterate over array(s) 'buffer')
default-unroll
, max-length
, or the widening delay.MSP430: added a heuristic that changes the default unroll parameter to 32 for repeat loops.
For example, given the repeat loop
rpt r7: addx.w r9, r12
the analysis will change the local default-unroll settings for the loop and report the change as:
eva-msp430: Info: Local default-unroll settings for loops:
* Loop 'main.L3' default-unroll = 32 ('repeat loop' heuristic)
mac
and macu
instructions.routine "test" { recursion bound: 0 .. <int>; }If no annotation is given, the default recursion bound is used. The path analysis phase will write to the report files how this bound is applied.
poptimize2ilp: info: in "test.c", line 16:
In routine 'f', at address 0x2000:
Applying recursion bound of 4 to irreducible recursion 'f' comprising the routines:
* f
* g
* h
Calls from the following routines are considered recursion entries:
* main
routine "test" { irreducible bound: 0 .. <int>; }If no annotation is given, the default loop bound will be used. If you need to prevent that from happening, simply set the bound to
inf
:
routine "test" { irreducible bound: inf; }
suppress message
annotation now also suppresses the message in HTML/XML report files.analysis_maximum_memory
)Info #3156: Annotation hints for init analysis to resolve computed control flow.
ais2 { # unresolved computed call ("report_fatal_error" -> computed(1)) collect initialization: "fatal_error_handler"; # unresolved computed call ("get_current_time" -> computed(1)) collect initialization: "get_tick_timer_handler"; }
routine "min" { not analyzed; stack effect: 555 bytes; }The new message now reads:
#3079: Assuming a stack usage of [0..555] bytes for routine 'min'.
For external and not analyzed routines, when the analyzer assumes that calling conventions are obeyed, it now also assumes a balanced stack effect. The effect is deduced from the calling instruction.
For TriCore, the effect of a ret
instruction is simulated if no
proper call*
, fcall*
. jl*
, syscall
,
trapv
or trapsv
has been used to call the external (or not analyzed)
routine, e.g. in case of tail calls.
As a result, some messages may change from
No assumptions are made on the stack effects for routine 'foo'.to
Annotation hint:ais2 { routine "_tx_thread_schedule" { obeys calling conventions: false; } }
Assuming a balanced stack effect for routine 'foo'.
Annotation hint:ais2 { routine "_tx_thread_schedule" { obeys calling conventions: <bool>; } }
Not analyzed code snippets are now always classified as violations of calling conventions. Consequently, the following messages will not be emitted anymore:
warning #3099:
In routine ':Anon_0x116e', at address 0x116e:
No assumptions are made on the stack effects for excluded code snippet ':Anon_0x116e'.
Annotation hint:ais2 { routine ":Anon_0x116e" { obeys calling conventions: false; } }
The analyzer now informs you if an “obeys calling conventions: true” annotation has been overruled:
Info #3114: In "foo/main.c", line 12:
In routine ':Anon_0x8001620', at address thumb::0x8001620:
In "foo.ais", line 13, column 5:
The analysis assumes a violation of calling conventions for routine ':Anon_0x8001620'.
Ignoring annotation that states the opposite.
<computation_task> <computation> <expression>...</expression> <result>...</result> <expectation>success</expectation> <messages> <message>...</message> ... </messages> </computation> </computation_task>
@groupname
)
for min/max functors. This allows easy composition of stack results for multiple analyses:
max(@StackAnalysisGroup)