Background
The normal cycle of developing a program is to edit source code, compile it, and then execute the resulting binary. However, sometimes this cycle can be too restrictive. We may wish to change the program while it is executing, and not have to re-compile, re-link, or even re-execute the program to change the binary. At first, this may seem like a bizarre goal, however there are several practical reasons why we may wish to have such a system. For example, if we are measuring the performance of a program and discover a performance problem, it might be necessary to insert additional instrumentation into the program to understand the problem. Another application is performance steering; for large simulations, computational scientists often find it advantageous to be able to make modifications to the code and data while the simulation is executing. Applications that can make use of this dynamic code adaptation system include:
- Performance Measurement Tools
- Correctness Debuggers (efficient data breakpoints)
- Execution drive simulations
- Computational Steering
We have created an Application Program Interface (API) to permit the insertion of code into a running program. The goal of this API is to provide a machine independent interface to permit the creation of tools and applications that use runtime code patching. This API is based on the idea of Dynamic Instrumentation described in [1, 2] and used in the example here. A variety of tools have been built using Dyninst.
Dyninst can be downloaded here. Or, you can go directly to our central GitHub Repository. Got an issue with Dyninst that you'd like to report? You can let us know using the GitHub Issue Tracker for our project.
We've compiled a list of tools that use Dyninst and papers (not by Dyninst developers) that use Dyninst in their work.
