Name

Kernel Instrumentation — Overview of eCos Kernel and Infrastructure instrumentation

Description

The kernel implements a simple macro based mechanism for tracing the flow of execution. It is designed for embedding many trace points, each with an optional small amount of associated data (e.g. that can be encoded in two 32-bit “argument” fields). The mechanism also allows for extending the instrumentation with further package specific event generation as required.

Instrumentation records will only be generated if the CYGPKG_KERNEL_INSTRUMENT) option is enabled, and then only if the relevant individual kernel event code sub-options are also enabled. The default state is for all the kernel instrumentation sub-options to be enabled.

[Warning]Warning

Some options, when enabled, will generate a large quantity of instrumentation records in a heavily loaded system and so care may need to be taken regarding the instrumentation that is enabled vs the instrumentation recording mechanism being used to avoid missing events. Depending on why the kernel instrumentation framework is being enabled (debugging, timing validation, etc.) the user can choose which events they wish to record by enabling only the specific CDL options required.

The tuning of the amount of instrumentation generated, and any buffering required to hold event records, is always a consideration when investigating systems and it may not be possible to have every instrumentation option enabled all of the time.

At its simplest, default, the kernel instrumentation stores event records in a memory buffer for subsequent extraction and post-processing.

However the instrumentation code generated can be over-ridden by a configuration providing a suitable CYGBLD_KERNEL_INSTRUMENT_WRAPPER_H header to override the default kernel implementation. This allows for other eCos packages, or for application specific support, to provide their own implementation.

The CYGPKG_INFRA infrastructure package also provides for other tracing mechanisms to be enabled. The provision of multiple “tracing” solutions reflects the different feature sets they provided. The user has the option for using the mechanism that best suits their needs, e.g. system level events, high-level application logic or performance, etc.

As an adjunct to the main kernel instrumentation support the infrastructure cyg_systrace.h header defines some macros used to instrument specific points in the eCos source (INFRA, KERNEL, HAL, etc.). The CYG_SYSTRACE_* support has been driven by the support required for specific features of 3rd-party trace tools.

The infrastructure package also provides the cyg_trac.h header which implements an alternative approach to tracing the execution path of code. The documentation for that trace mechanism is provided in the actual header file.