Enabling the OS awareness
The below implementation in provider.py, assumes
myos has a global variable called
tasks listing the OS tasks in an array and another global variable
scheduler_running indicating that the OS has started scheduling tasks.
# this script implements the Java interface IOSProvider from osapi import DebugSessionException def areOSSymbolsLoaded(debugger): return debugger.symbolExists("tasks") \ and debugger.symbolExists("scheduler_running") def isOSInitialised(debugger): try: result = debugger.evaluateExpression("scheduler_running") return result.readAsNumber() == 1 except DebugSessionException: return False def getOSContextProvider(): return None def getDataModel(): return None
osapi module in the import statement at the top of
provider.py is a collection of wrappers around Java objects
and utility functions. The file osapi.py itself can be found in
JAR file com.arm.debug.extension_<version>.jar.
Connecting to a running target and loading symbols manually for the OS shows both
- On connecting to the target running the OS, without loading symbols, the
Debug Control view displays
Waiting for symbols to be loaded.
Figure 14-3 myos waiting for symbols to be loaded
- After loading symbols for the OS, with the target still running, the Debug
Control view now displays Waiting for the target to
At this point,
areOSSymbolsLoaded()has been called and returned true, and the debugger is now waiting for the target to stop to call
Figure 14-4 myos waiting for the target to stop
- As soon as the target is stopped, the Debug
Control view updates to show the OS awareness is enabled.
At this point,
isOSInitialised()has been called and returned
Figure 14-5 myos Enabled
All Threadsfolders are always empty until you implement thread awareness using
NoteYou can show the
Coresfolder by enabling the Always Show Cores option in the View Menu of the Debug Control view.
- Another case worth mentioning is where
false. This can happen for instance when connecting to a stopped target, loading both the kernel image to the target and associated symbols in the debugger and starting debugging from a point in time earlier than the OS initialization, for example, debugging from the image entry point.
In this case, the Debug Control view shows Waiting for the OS to be initialised as
scheduler_runningis not set to
1yet, but symbols are loaded:
Figure 14-6 myos waiting for the OS to be initialised
Without the call to
isOSInitialised()the debugger lets the awareness implementation start reading potentially uninitialized memory, which is why this callback exists. The debugger keeps calling back to
isOSInitialised()on subsequent stops until it returns true, and the OS awareness can finally be enabled.