14.4 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

The 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 areOSSymbolsLoaded() and isOSInitialised() stages distinctly.

  • 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
    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 stop.

    At this point, areOSSymbolsLoaded() has been called and returned true, and the debugger is now waiting for the target to stop to call isOSInitialised().

    Figure 14-4 myos waiting for the target to stop
    myos waiting for 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 true.

    Figure 14-5 myos Enabled
    myos Enabled


    Both the Active Threads and All Threads folders are always empty until you implement thread awareness using getOSContextProvider().

    Note:

    You can show the Cores folder by enabling the Always Show Cores option in the View Menu of the Debug Control view.
  • Another case worth mentioning is where areOSSymbolsLoaded() returns true but isOSInitialised() returns 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_running is not set to 1 yet, but symbols are loaded:

    Figure 14-6 myos waiting for the OS to be initialised
    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.

Non-ConfidentialPDF file icon PDF versionARM 100953_0527_00_en
Copyright © 2010–2017 ARM Limited or its affiliates. All rights reserved.