[Leapfrog: First Look]
Software Probes Monitor And Repair Applications
The SensorPoint Technology puts new code in existing applications for debugging and patch delivery.
A program that never needs changing or fixing is a rare one. That's why debugging, monitoring, and patching tools are in every programmer's toolbox. While some of these tools are akin to rope and stone knives, more advanced development environments provide dynamic insight into applications. This is where Wind River's SensorPoint technology fits.
SensorPoints are part of Wind River's Lab Diagnostics and Device Management programs, which address the entire development and deployment cycle. It's an ambitious approach that so far has been well-received, though it is still growing.
SensorPoint support is integrated with Wind River's Eclipse-based Workbench integrated development environment (IDE). It requires tight coupling between all development components, including the IDE, compiler, linker, and diagnostic tools (see "SensorPoints,"). SensorPoints can be added not only to applications with debugging hooks but also to production applications that lack this information—one reason for this tight integration requirement.
PATCHING PROGRAMS Developers can add script code into applications while they are debugging, allowing them to monitor the application or change its operation on the fly for what-if scenarios. While useful, past implementations tended to be restricted to development work on applications with debug information. The process also tended to be unwieldy as the number of modifications grew. Most were used in a transient fashion.
Application patching is similar. This is normally done so a small set of patches can be delivered using a larger application to generate a new version with the patches incorporated. It makes delivery of these changes faster and easier, but the changes must be applied before an application is run. Patching systems are rarely used for debugging purposes, and selective addition of changes is sometimes difficult.
Finally, there are logging and tracking tools that can be added at compile time or run time. Some require diagnostic information, while others do not. SensorPoints tie all these approaches together.
PLACING PROBES SensorPoints are C code compiled to machine code so execution is as efficient as the original application. Linked into an application at run time, they can either replace an existing block of code or add code (Fig. 1). In the latter, the linkage to the new code overwrites one or more instructions that must be replicated in the new code so the application continues to run as originally intended.
Adding a SensorPoint might be as simple as adding a jump instruction to the new code that ends in a jump back to the old code after the newly added instruction. But in practice, many things can make the process harder. For example, some architectures use different instruction sizes for jumps, so any code overwritten by the new addition must be included in the SensorPoint code.
Likewise, the overwritten code may be the jump target from other parts of the application. These must be modified appropriately as well. The task becomes even more complex when optimized code is part of the process. Such large numbers of variables require tight integration with the make system, compiler, and linker.
SensorPoints are designed to be reused. They're defined in C source code using a slightly modified syntax that makes it easier to incorporate this code into application code. This tends to be of little interest for logging or debugging code, but it is imperative for patches that need to be rolled back into the main application source-code tree.
The source code for a SensorPoint is maintained in separate files from the application code. This makes management significantly easier. It also makes the process much easier to manage using source-code management tools.
Reprints
