diff -r 218e49ed806f -r 617a89f9dffc core/com.nokia.carbide.cpp.doc.user/html/reference/view_symbian_kernel.htm --- a/core/com.nokia.carbide.cpp.doc.user/html/reference/view_symbian_kernel.htm Tue Sep 21 10:33:50 2010 -0700 +++ b/core/com.nokia.carbide.cpp.doc.user/html/reference/view_symbian_kernel.htm Tue Sep 21 15:50:51 2010 -0500 @@ -13,7 +13,7 @@

The Symbian OS Data view displays the processes and threads for the suspended debug session based on the selection in the Debug view. Read-only data is displayed for ARM build configurations. To open the Symbian OS Data view select Window > Show View > Symbian OS Data when the Debug perspective is visible or select Window > Show View > Other..., then expand the Carbide.c++ folder and select Symbian OS Data when the Carbide C/C++ perspective is visible. Click Ok to display the Symbian OS Data window (Figure 1).

NOTE The Symbian OS Data view works with the debugger and will only display data during a live debug session. The Symbian OS Data view is not supported for emulator debugging, and will not show anything during emulator debug.

The Symbian OS Data view reveals kernel data in the Symbian OS running on the device being debugged. The kernel data displayed is always that of the device with the currently selected thread or process in Debug view. If you are debugging two devices at the same time, the content of the view will change when focus is switched from a thread on one device to a thread on another device. The kernel data includes more than just processes and threads.

For the stop mode debugger and the crash debugger, all the data listed above is supported. For the Application and System CODA debuggers, the chunks and libraries views are not supported. The Symbian OS Data view is not supported for the emulator debugger and will show nothing during an emulator debug session. During a stop mode debug session or a CODA debug session, you are able to select a process or a thread in the Symbian OS Data view and attach the debugger to it for source level debugging if the binary is listed in the Executables view. Binaries listed in the Executable view can be source level debugged. Binaries not listed in the Executables view can only be assembly code debugged in the Disassembly view.

For the stop mode debugger and the crash debugger, all the data listed above is supported. For the Application and Symbian OS Device debuggers, the chunks and libraries views are not supported. The Symbian OS Data view is not supported for the emulator debugger and will show nothing during an emulator debug session. During a stop mode debug session or a CODA debug session, you are able to select a process or a thread in the Symbian OS Data view and attach the debugger to it for source level debugging if the binary is listed in the Executables view. Binaries listed in the Executable view can be source level debugged. Binaries not listed in the Executables view can only be assembly code debugged in the Disassembly view.

NOTE Any executable must be included in the Executables view before it can be debugged.

When the Time interval for auto-refreshing OS View option is enabled (which is on by default except for crash debugger), the data in the Symbian OS Data view will be auto-refreshed. Note that "auto-refresh" has a different meaning in different debuggers. During a stop mode debug session, the view will refresh data whenever the debugged program on the device is stopped and shows data as stale (greyed out) when the program is running. During a CODA debug session, the View will refresh data at a time interval regardless of whether the debugged program is stopped or not. The time interval is specified by an option in the Carbide.c++ global preference panel, which is five seconds by default.

When auto-refresh is turned off, the debugger will not automatically refresh data in the View and will show the data as stale (greyed out). However you can manually refresh the data by clicking on the "Refresh" button in the View. Usually you may want to turn off the auto-refresh if you think it is slowing down your debug operations such as stepping.