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 (). 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.