Several research and commercial groups use the DyninstAPI. This is a
partial list; we welcome new users.
In the Fall of 2004, Silicon Graphics was awarded a DOE contract to develop a suite of open source performance tools for parallel systems. They chose Dyninst as their underlying instrumentation layer and the University of Wisconsin as a partner and subcontractor on this effort. The Wisconsin group is responsible for supporting the IA32, IA64, and AMD64/EM64T ports (the AMD64 port is being done in cooperation with the University of Maryland). The Wisconsin group is also responsible for revising and improving the Dyninst test structure, reducing Dyninst start-up time by supporting lazy parsing, support the bproc cluster process control interface, and general bug fixing.
We have worked closely with the IBM DPCL team to converge the IBM BPatch layer to work with the main Dyninst code base. By doing this, DPCL was made available on additional platforms by using the Dyninst code as an instrumentation substrate. When IBM was developing DPCL, they forked the source code from the main Dyninst tree. In the meantime, many new features were added to Dyninst (including arbitrary instrumentation, control flow graphs, etc.). By re-uniting these two interfaces, we were able to ensure that future version of DPCL will be able to take advantage of advances in Dyninst. While there was little new research in this effort, it required carefully engineering to provide compatibility between the two interfaces.
DynaProf (Philip J. Mucci) provides a command line performance tool that includes the functionality of traditional profiling tools such as prof and gprof, but uses the Dyninst infrastructure to allow the tool to work with binary programs without needing recompilation.
P. Mucci, Dynaprof. http://www.cs.utk.edu/~mucci/dynaprof.
Emilio Luque's group at University Autonoma of Barcelona has developed
Dynamic Kappa-Pi, a tool for identifying important performance
bottlenecks in message passing programs. The Dynamic Kappa-Pi tool
extends their prior work which was based on static instrumentation.
Al Malony's TAU group at the University of Oregon has been using Dyninst to develop an on-demand version of the integrated TAU instrumentation. From Prof. Alan Malony:
We have been working with Dyninst in the TAU project for nearly three years. We use Dyninst to insert instrumentation for performance measurement using the TAU performance system. The Dyninst API is used to build code snippets for calling the TAU performance measurement library at subroutine entry and exit points, and then to insert these snippets into the executable code for selected routines.
We have also implemented this approach in the context of MPI programs, as part of work for a LLNL/LANL ASCI Level 3 contract. This allows multiple instrumentors to simultaneously instrument each executable image prior to its execution.
TAU Version 2.11 ships with support for Dyninst.
Clearly, Dyninst has given TAU the ability to instrument application software for performance measurement in cases where source code is unavailable. This is a huge win for our work since it increases TAU's instrumentation flexibility and robustness. We can easily combine source instrumentation with dynamic instrumentation, deciding on different instrumentation strategies depending on needs and requirements. Our experience with dyninst has also proved valuable for our current work to integrate DPCL in TAU.
In the future, we hope to use Dyninst in TAU to support dynamic instrumentation of high-level parallel constructs, using TAU's performance mapping support, and to enable performance measurement control and adaptation at runtime.
Dan Reed's group at the University of North Carolina is using Dyninst to insert SVPablo/Autopilot performance probes into unmodified binary programs at run-time. The goal is to instrument loops and procedures. From Dr. Celso Mendes, in the Pablo group:
There are several benefits in having this kind of dyninst-based instrumentation as a complement to SvPablo's capabilities. As an example, it is possible to instrument parts of an application for which there is no source code available (e.g. some system libraries) or to instrument codes that are originally written in a language that is not supported by SvPablo's parsers. With dyninst, one can also effectively insert or remove SVPablo-compatible instrumentation, at execution time, according to dynamic conditions. This capability can potentially be explored with SvPablo's interface to Autopilot, where performance data captured by sensors could be analyzed in real-time, and additional instrumentation points could be inserted or removed by Autopilot's actuators.
Jesus Labarta's group at the Universitat Politecnica de Catalunya have
used (and are currently using) Dyninst in a variety of ways for
performance instrumentation. For example, they have used Dyninst to
support their scalable trace generation scheme. Dyninst allows them to
adjust what they trace while a program is executing. They are
currently using Dyninst, in collaboration with researchers at Los
Alamos and San Diego Supercomputer Center, to collect performance data
to model memory systems.
F. Freitag, J. Caubet, and J. Labarta, A Trace-Scaling Agent for Parallel Application Tracing, 14th IEEE International Conference on Tools with Artificial Intelligence (ICTAI'02). November 2002, Washington, DC.
The ToolGear toolkit developed at LLNL uses either DPCL or Dyninst as its instrumentation infrastructure.
Satoshi Matsuoka's group at the Technical University of Tokyo is using
Dyninst in support of the NAREGI Japan national grid project. They are
using Dyninst to virtualize a process to execute in a portable manner
by intercepting its key operating system calls.
S. Matsuoka, The NAREGI Server Grid Resource Management Framework, HPC Asia 2004 NAREGI Workshop. July 2004.
Allan Snavely at SDSC has used Dyninst as the infrastructure to gather
memory traces as part of his Metasim project. In particular, he
uses the ability of Dyninst to instrument all the load and store
instructions in a program to gather information about the memory
access patterns of programs. He then uses this information to predict
how changes to the memory system of future architectures might impact
the performance of the previously measured program.
L. Carrington, N. Wolter, A. Snavely, and C. B. Lee, Applying an Automated Framework to Produce Accurate Blind Performance Predictions of Full-Scale HPC Applications, UGC 2004. June 2004, Williamsburgh, VA.
Jaydeep Marathe and Frank Mueller at North Carolina State University
have been using Dyninst in their work to detect Memory Performance
Bottlenecks. In particular, they have been using Dyninst as a static
Binary rewriting tool.
Los Alamos Tools Development (from Chip (David) Kent)
The Alexandria Project: Dyninst is being used to intercept system calls so that the inputs to and outputs from our simulations can be recorded. This allows simulations to be exactly reproduced. This also allows simulation results to be associated with bug reports so that the quality of the results can be gauged. We have discussed adding Javelina's functionality in the future (see below). This will allow us to record what portions of the code base were executed during a simulation.
Javelina: Javelina is an advanced code coverage tool. Javelina currently uses ATOM for instrumentation and only works on Tru64. Dyninst is being used to 1) reduce the overhead for collecting data (by removing instrumentation) and 2) improve portability (especially to Linux).
While these papers are unclassified and are available from LANL as
technical reports, they will be published in the classified
proceedings of the Nuclear Explosives Code Development Conference 2004
(still in press).
D. R. Kent, IV, S. R. Runnels, and E. E. Dougherty, Analysis
Tool for Studying Application-Based Source Code Coverage,
LA-UR-04-8542, Los Alamos National Laboratory, 2004.
D. R. Montoya and D. R. Kent, IV, Alexandria: Simulation Information Tracking, LA-UR-04-8543, Los Alamos National Laboratory, 2004.
Dawn Song's group at CMU use Dyninst as a instrumentation
layer in their research. Dyninst is used to monitor
exploit-vulnerable stack modification locations.
David Brumley, Dawn Song, Jad Chamcham, Xeno
Kovah. Vulnerability-Specific Execution Filtering for Exploit
Prevention on Commodity Software. 13th Annual Network and
Distributed System Security Symposium '06, February 2006.
J. L. Rrushi and E. Rosti, "Function Call Tracing
Attacks to Kerberos 5", Detection of Intrusions
and Malware & Vulnerability Assessment (DIMVA), July 2005.
Dyninst was used to disable the license checking of FrameMaker.
B. P. Miller, M. Christodorescu, R. Iverson, T. Kosar, A. Mirgorodskii, and F. Popovici. Playing inside the black box: Using dynamic instrumentation to create security holes. Parallel Processing Letters 11(2,3):267-280, 2001.
Rean Griffith (Columbia) works on the STEM project and is using
Dyninst to inject emulation code at run-time; details about the
project were not given.
Marc Eisenbarth (Columbia) uses Dyninst to replace functions on
multi-threaded programs; details about the project were not given.
P. Unnikrishnan and G. Chen and M. Kandemir and
D. R. Mudgett, "Dynamic Compilation for Energy Adaptation", 2002
IEEE/ACM International Conference on Computer-aided Design, San
Jose, California, pp. 158-163.
T. Mohan, B.R. de Supinski, S.A. McKee, F. Mueller. A. Yoo,
M. Schulz, "Identifying and Exploiting Spatial Regularity in Data
Memory References", SC03, Phoenix, AZ, November 2003.
Charles Zhang and Hans-Arno Jacobsen, "TinyC2:
Towards Building a Dynamic Weaving Aspect Language for C",
Foundations of Aspect-Oriented Languages 2003, Boston,
S. Sangeti, T. Ramasamy, J. Murugan, "Runtime Weaving
of Aspects using Dynamic Code Instrumentation Technique for Building
Adaptive Software Systems", 1st AOSD Workshop on Aspects,
Components, and Patterns for Infrastructure Software, Enschede,
Netherlands, April 2002.