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.
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 .kev) file.
to open the standard file selector, then choose the appropriate kernel event log (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).
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
(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.
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.
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.
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.
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.
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.