Please enable JavaScript to view this site.

winIDEA Help

Version: 9.21.239

Advanced Profiler Configuration

This chapter explains advanced Profiler settings, e.g. OTM / ITM encoding, PC  sampling pool etc.

 

Open Advanced Profiler Configuration dialog to configure the advanced Profiler settings per Process via View / Analyzer Configuration / Profiler / Advanced.

 

AnalyzerConfigurationAdvancedProfilerConfiguration

 

Tail optimization analysis

Compilers perform several kinds of optimizations on the function exit code. Profiler must recognize:

tail-merge, where compiler optimization effectively moves part of function A code body into another function B (e.g. the exit from the function).  Execution of function B should therefore be attributed to function A. If the analyzer is not aware of the tail-merge optimization, the exit from function A will instead be attributed to function B.

tail-call, where optimization occurs when function A calls function B just before it exits. Instead of using a call op-code, a branch is used, so when function B returns, effectively function A returns too. If the analyzer is not aware of tail-call optimization, the function A will never return.

Tail optimization analysis is only possible in range mode. This analysis requires a higher level of debug information quality and it relies on object code analysis. If the analysis algorithm fails, Profiler session aborts. In such case the tail optimization analysis can be disabled to revert to regular range mode.

 

Allow function without exits

When checked, Profiler allows functions without exits (typically main on embedded applications).

 

Function instrumentation prefix

If data profiling is used for function profiling via instrumentation, numerical values are used to represent functions. Instrumentation prefix is added to the function name to differentiate between function definition and the definition of the numerical value representing this function. By default it is set to _ipf, which is also the prefix used in examples.

 

Stack Killers

Functions which terminate the task stack should be specified here. Usually this will be just the central OS scheduler function. If there are multiple, separate them with commas.

 

Standard Stack Killers

Include standard functions from known OSes which terminate the entire task stack (e.g. osTerminateTask by Vector).

 

OTM/ITM encoding - Encoding of the instrumentation messages.

 

Prefix hexadecimal numbers with 0x - Prepend 0x when displaying hexadecimal values.

 

Ignore context reactivation - By default the Profiler ignores repeated task IDs and considers that the same task/IRQ continues without interruption. Optionally, re-activation can be considered as a separate activation of the context. The changed interpretation will be reflected in the statistics for the task.

 

Merge data areas - If insufficient hardware comparators are available, data areas are merged. This can increase data trace bandwidth considerably and cause OCT port overflows.

 

PC sampling pool - Results of PC Sampling are calculated from last N (1000 by default) events.

 

Discard execution in unknown context - Before a Task/IRQ context is known, the code execution can optionally be ignored. If on the other hand the application is profiled from CPU start, the OS is not active yet and the unknown context is a valid state, the option should be disabled.

Technique will increase the data trace bandwidth and could lead to trace port overflow if the data areas of interest are far apart in terms of address locations and frequently written variables lie between them. In such case the data variable layout in the application could be rearranged so that variables of interest are closer together.

 

Merge data areas - By default the Analyzer will attempt to use one hardware data comparator per data area. On most on-chip trace systems, the number of these comparator is small and insufficient. The Profiler can merge multiple data areas in a single range, thus recording multiple data areas using just a single comparator.

 

Process indirect data accesses - Data accesses made on a location that does not directly reflect the variables are also processed. See two examples below.

 

 

Example 1

From Trace we get information that write to location 0x1000 was made with size of 0x4bytes and value of 0x12345678. In Profiler we configured that we want to observe variable that is at location 0x1002 and size of 0x2bytes

If option is disabled (default behavior): Write to this location (0x1000) will be ignored since this location is not the same as location of variable(0x1002).

If option is enabled: Variable at location 0x1002 will be assigned with new data. If memory is in little endian, then variable will have value 0x1234 else 0x5678.

 

 

Example 2

variable "g_SINT32" location 0x4000'0090 size 0x4

variable "g_SINT8"  location 0x4000'0094 size 0x1

variable "isCustomTest" location 0x4000'0095 size 0x1

 

 

With disabled option

With enabled option

ProfilerProcessIndirectDataAccess
ProfilerProcessIndirectDataAccess2

 

Copyright © 2024 TASKING Germany GmbH