Code authorship information is important for analyzing software quality, performing software forensics, and improving software maintenance. However, current tools assume that the last developer to change a line of code is its author regardless of all earlier changes. This approximation loses important information. We present two new line-level authorship models to overcome this limitation. We first define the repository graph as a graph abstraction for a code repository, in which nodes are the commits and edges represent the development dependencies. Then for each line of code, structural authorship is defined as a sub graph of the repository graph recording all commits that changed the line and the development dependencies between the commits, weighted authorship is defined as a vector of author contribution weights derived from the structural authorship of the line and based on a code change measure between commits, for example, best edit distance. We have implemented our two authorship models as a new git built-in tool git-author. We evaluated git-author in an empirical study and a comparison study. In the empirical study, we ran git-author on five open source projects and found that git-author can recover more information than a current tool (git-blame) for about 10% of lines. In the comparison study, we used git-author to build a line-level model for bug prediction. We compared our line-level model with an existing file-level model. The results show that our line-level model performs consistently better than the file-level model when evaluated on our data sets produced from the Apache HTTP server project.

Binary instrumentation allows users to inject new code into programs without requiring source code, symbols, or debugging information. Instrumenting a binary requires structural modifications such as moving code, adding new code, and overwriting existing code; these modifications may unintentionally change the program's semantics. Binary instrumenters attempt to preserve the intended semantics of the program by further transforming the code to compensate for these structural modifications. Current instrumenters may fail to correctly preserve program semantics or impose significant unnecessary compensation cost because they lack a formal model of the impact of their structural modifications on program semantics. These weaknesses are particularly acute when instrumenting highly optimized or malicious code, making current instrumenters less useful as tools in the security or high-performance domains. We present a formal specification of how the structural modifications used by instrumentation affect a binary's visible behavior, and have adapted the Dyninst binary instrumenter to use this specification, thereby guaranteeing correct instrumentation while greatly reducing compensation costs. When compared against the fastest widely used instrumenters our technique imposed 46% less overhead; furthermore, we can successfully instrument highly defensive binaries that are specifically looking for code patching and instrumentation.

The Dyninst binary instrumentation and analysis framework distinguishes itself from other binary instrumentation tools through its abstract, machine independent interface; its emphasis on anywhere, any-time binary instrumentation; and its low overhead that is proportional to the number of instrumented locations. Dyninst represents the program in terms of familiar control flow structures such as functions, loops, and basic blocks, and users manipulate these representations to insert instrumentation anywhere in the binary. We use graph transformation techniques to insure that this instrumentation executes when desired even when instrumenting highly optimized (or malicious) code that other instrumenters cannot correctly instrument. Unlike other binary instrumenters, Dyninst can instrument at any time in the execution continuum, from static instrumentation (binary rewriting) to instrumenting actively executing code (dynamic instrumentation). Furthermore, we allow users to modify or remove instrumentation at any time, with such modifications taking immediate effect. Our analysis techniques allow us to insert new code without modifying uninstrumented code; as a result, all uninstrumented code executes at native speed. We demonstrate that our techniques provide this collection of capabilities while imposing similar or lower overhead than other widely used instrumenters.

Abstract Profiling is a key technique for achieving high performance. Call‐path profiling is a refinement of this technique that classifies a function's behavior based on the path taken to reach the function. This information is particularly useful when optimizing programs that use libraries, such as those for communication (MPI or PVM), linear algebra (ScaLAPACK), or threading. We present a new method for call‐path profiling called incremental call‐path profiling. We profile only a subset of the functions in the program, allowing the use of more complex metrics while lowering the overhead. This combination of call‐path information and complex metrics is particularly useful for localizing bottlenecks in frequently called functions. We also describe the implementation and application of iPath, an incremental call‐path profiler. iPath was used to profile two real‐world applications: the MILC su3_rmd QCD distributed simulation and the Paradyn instrumentation daemon. In both applications we found and removed call‐path‐specific bottlenecks. Our modifications to su3_rmd reduced the running time of the program from 3001 to 1652 s, a 45% decrease. Our modifications to the Paradyn instrumentation daemon greatly increased its efficiency. The time required to instrument our benchmark program was reduced from 296 to 6.4 s, a 98% decrease. Copyright © 2006 John Wiley & Sons, Ltd.