Importing and exporting kernel event trace results

The System Profiler can import kernel event trace results generated outside of the IDE environment. When you examine trace results in the tool's editor, you can export a subset of events, to share or view the most relevant trace data. You can also export profiling data generated by any application with function instrumentation, into a new profiling session.

Importing kernel event trace results

Unlike the tools that analyze individual applications, the System Profiler doesn't have an import wizard. There are no tool-specific steps for importing trace results. You can simply choose File > Open File to open the standard file selector, then choose the appropriate kernel event log (.kev) file.

If you start kernel event tracing outside of the IDE, whether through tracelogger or an application that calls TraceEvent() to manage event logging and data capturing, the resulting log file gets written to whatever target location was specified by the tool. Often, the file is named tracebuffer.kev and is found in either /dev/shmem/ or the directory in which the tool ran. You must then upload the file to a suitable host location using the Target File System Navigator.

You don't need to import the results from a kernel event trace started from the IDE, because the log file is uploaded to the active workspace as soon as the trace finishes. Specifically, the file is copied to the directory for the target connection used to run the trace (i.e., workspace_dir/target_conn_name).

Exporting kernel event trace results

There are no tool-specific steps for exporting kernel event trace results. With the trace results open in the System Profiler editor, you can simply choose File > Save As (the editor must be in focus) to save a copy of the kernel event data.

A new log (.kev) file is created, based on the currently open log file. You can restrict the data exported to this new file so you keep only the information most relevant for your system analysis. In any editor pane except Summary, you can select a region of the graph (by clicking and dragging the mouse), then export only those kernel events that occurred in that selected timeframe and not the entire trace period. This is done by clicking the Selected radio button under the Event Range panel in the Save As dialog.

You can also restrict the exported data to the event owners and types named in the Filters view and currently displayed in the editor pane. This is done by checking the Apply current filters box under the Event Filters panel in the Save As dialog.

The new log file contains the same attribute information as the original log file, including the system version, boot time, number of CPUs, and so on. All events in the new file have timestamps that are relative to the start time of the exported trace data, not the start time of the original trace. For example, suppose that in the original trace, a given process was created exactly 5 seconds since the start. If you then export the trace data from exactly 3 seconds onwards, the new file contains a creation event for this process with a timestamp of 2 seconds.

Regardless of how you ran the kernel event trace, when the log file has been copied into the workspace, you can open it from the Project Explorer. The log file is found either in the project for the target connection used to initiate the trace or wherever you uploaded it to. You really need to export the results only if you want to make a copy of them or save a data subset.

Exporting profiling data from trace results

The IDE lets you start an application with function instrumentation enabled and a kernel event trace at the same time. This workflow makes the application log timestamped function entries and exits as kernel events, so its function runtime data appear in the kernel event trace results. When viewing these results, you can export these data into a new Application Profiler session. To do this:
  1. With the trace results open in the System Profiler editor, switch to the Timeline pane by clicking the Switch Pane dropdown in the editor controls (Icon: Switch Pane dropdown) and selecting Timeline.
  2. Optional: If you want to export profiling data for only a specific timeframe, click and drag the mouse over the period of interest within the Timeline display. You may have to zoom in or out to see the appropriate timeframe. If you don't select a particular area, event data throughout the trace period are exported.
  3. Right-click and choose Open with QNX Application Profiler.

    The Import Application Profiler Data dialog is opened, and it contains the name of the kernel event log file in the Import From File field.

  4. In Executable File, specify the executable binary for which you want to export profiling data.

    You can manually enter a file path or click Browse to pick a file from the workspace or filesystem through a file selector. The ${workspace_loc:*} variable is also supported.

  5. In the Libraries Search Path panel, add the paths of any libraries that the profiled application uses.

    These paths tell the IDE where to find shared libraries referenced by the profiling data. This UI control behaves the same way as the Libraries tab in the launch configuration.

    When you've defined the necessary paths, if the profiled application uses source code compiled on another machine, click Next; otherwise skip to Step 7.

  6. Optional: In the Binary Path window, specify any additional required source code paths.

    The Source Lookup Path panel lists the host paths that the IDE should search to find source code that was part of the instrumented binary but wasn't compiled on the host. This UI control behaves like the Source tab in the launch configuration.

  7. Click Finish.

    The IDE switches to the QNX Analysis perspective and begins importing the data into a new Application Profiler session, which it displays in the Analysis Sessions view. The session follows the standard naming convention consisting of the binary that produced the profiling results followed by a new, unique session number. You can rename the session by right-clicking its entry and choosing Rename.

Note: You can run as many instrumented binaries as you like while the kernel event trace proceeds. Each of these binaries logs its own function enter and exit events to the trace and you can filter the Timeline display to show the events from any subset of the instrumented binaries. However, you have to export the function event data generated by each application into its own profiling session.