[Mehmet Altinel, UMD]
Various demonstrations including the ability to capture the output of an
already-running process and save it to a file by piggy-backing the
"write" system call (re-tee) and a simple conditional
breakpointer using run-time generated snippets which perform checks on a given
condition to decide whether to call DYNINSTbreakPoint or not.
A gdb-like scripting language and shell interfacing to dyninst
and incorporating a Java-to-dyninst snippet compiler for higher-level
dynamic program/process analysis, control and instrumentation.
Without knowledge of application source code, run-time binary code
rewriting using dyninst is used to circumvent calls to functions making
license checks in commercial products, allowing full use of the
products whenever the license server is temporarily unavailable.
[Mihai Christodorescu]
Scenario: it's late evening, and you are using your licensed copy of
Adobe Framemaker and working towards a rapidly approaching important
deadline, when the machine on your network with the license server goes
down (or you lose the network connection) and you can no longer work on
or save your documents. In this demonstration, Adobe FrameMaker
license checks are bypassed on SPARC/Solaris, and full use of the
product is restored, allowing you to meet your deadline.
Dynamic Code Coverage Tool implemented using dyninstAPI.
[Mustafa Tikir, UMD]
The 099.go benchmark of SPEC95 will be used as a long running mutatee
program for this demonstration of the reduction in instrumentation when
dominator tree information is used for each function. Source code
coverage percentage and instrumentation execution percentage will also
be displayed during the instrumentation code deletion intervals.
Using the Dyninst API, the process Hijacker can attach to a running
application process, inject a Condor checkpoint library, disconnect the
process's system library and connect in a new one based on Condor's
remote system call stubs.
The process can then be checkpointed, migrated to another host of the
same type, and its execution continued.
Note that the application process did not require any special
preparation (compiling or linking) to be able to be checkpointed and migrated.
[Victor Zandy]
Hijacking of a running, unmodified Java VM application process and
its migration to a remote machine.
Application object/process image analysis functionality of the Dyninst
API is exploited to inspect an application (and its associated run-time
libraries) and extract information about the modules and functions from
which it is composed. The application (and libraries) need not be
specially prepared, as analysis can be performed on modules which may
have been both optimized and had their symbol table removed.
Instrumentable function entry and exit points are listed, along with
function call sites.
The Dyninst API is used to attach to a running (unprepared) process,
dynamically load the specified tracing library and insert calls at
appropriate places in the user program to the corresponding tracing
functions. The resulting execution trace generated can subsequently be
visualized and analysed with various off-line tools. This method can be
used with various tracing libraries, selectable during application
execution and without prior modifications or special linking.
[Chris Chambreau]
An MPICH application can be dynamically annotated with calls to the
VAMPIRtrace library
for viewing with
VAMPIR or the
Pablo
Trace Library for viewing with Pablo.
Autopilot sensor/actuator annotator:
A simple dyninstAPI-based mutator loads the
Autopilot sensor/actuator library into the specified (unmodified)
application process and splices calls to the requisite sensor functions.
The process subsequenly registers itself with its Autopilot controller,
which takes over the sensor management to enable collection of
pertinent measurements and adaptive resource management.
This utility uses the Dyninst API to provide a trace of all function
calls and returns of an arbitrary program: fntrace is thereby
a useful supplement to traditional debuggers that often miss this
feature. It works by instrumenting the entry and exit points of all
functions in the traced program with code that calls printf to
output a trace record. When provided with additional information on the
functions' signature, the input parameters and return values of such
calls can also be part of the trace.
[Roland Wismüller, TUM]
(demo available on demand)
OMIS and OCM are
two projects at LRR-TUM
building a monitoring infrastructure for parallel and distributed
systems. For the monitoring of calls to the parallel programming
library PVM, the current implementation of the OCM uses a
statically-instrumented version of PVM created by binary wrapping: this
has the disadvantage that applications need to be relinked in order to
monitor them. Therefore, an experimental version of the OCM was built
that uses the Dyninst API for the monitoring of PVM calls. The
challenge of this experiment was the fact that both the Dyninst API and
the OCM need to control the monitored process using the /proc
interface, which may result in unintended interferences. However, since
the Dyninst API can be completely detached from the monitored process
after instrumentation is done, this problem could be solved by taking
extra care on the initialization and cleanup phases of both OCM and the
Dyninst API.
[Roland Wismüller, TUM]
(demo unavailable at this time)
FIRST, a Framework
for Interoperable Resources, Services and Tools, provides
parallel tool developers with a centralized view of the functionality
provided by the Dyninst API managing a collection of distributed application
processes. Its ObjectCodeBrowser provides an interface to the
instrumentation points in the target program, allowing tool builders to
concentrate on what instrumentation needs to be placed rather than
where. Inter-process interfaces are defined using CORBA IDL and Ptools Portable Timer
Routines are used for timing.
[Radu Prodan & John Kewley, CSCS]
(demo unavailable at this time)
The MUTT
Memory Utilization Tracking Tool developed as a
Ptools project and uses dyninst to examine and annotate subject
application processes. MUTT augments the available off-the-shelf memory
utilization tracking capabilities for the SGI Origin, presenting
run-time maps of how and where memory is utilized.
[Federico Bassetti, LANL & Phil Mucci, UTK]
(demo unavailable at this time)
The TAU Tuning and Analysis
Utilities suite has incorporated dyninst to enable run-time process
profiling & tracing instrumentation in addition to its source-code, compiler
and linker-level capabilities.
[Sameer Shende, U.Oregon/LANL]
(demo unavailable at this time)
Last modified:
Sun Mar 19 20:44:38 CST 2000
by
wylie
