J. R. Larus and T. Ball. Rewriting executable files to measure program behavior. Software Practice and Experience, 20(2):197--218, February 1994.  Home/Search   Document Details and Download   Summary   Related Articles   Check

.... or OS monitors that provide access to process execution states, and the situation may be even worse in networked environments [21] A di#erent approach hinges upon program instrumentation, i.e. on augmenting the source object executable code to emit events that contain monitoring information [2, 3, 14, 23]. Instrumenting source code has the advantage of referring to variable names more directly and treating data more semantically , but typically requires implementing an auxiliary parser or compiler. Moreover, not all platforms provide high level primitives for accessing every aspect of the ....

J.R. Larus and T. Ball. Rewriting executables files to measure program behavior. Software - Practice and Experience, 24(2):197--218, 1994.

....TAU uses the POMP interface in conjunction with OPARI for instrumentation of OpenMP programs. 2.4 Binary instrumentation Executable images can be instrumented using binary code rewriting techniques, often referred to as binary editing tools or executable editing tools. Systems such as Pixie, EEL [9] and PAT [10] include an object code instrumentor that parses an executable and 8 rewrites it with added instrumentation code. PAT can be used for call site profiling and instrumentation at the routine level as well as gathering routine level hardware performance statistics. Pixie can count basic ....

Larus, J. and T. Ball, Rewriting Executable Files to Measure Program Behavior. Software Practice and Experience, 1994. 24(2): p. 197-218.

....output and produces C macros for code emission, which we have then used to rewrite a Java JIT backend. 1 Introduction Binary tools such as assemblers, debuggers, disas semblers, dynamic code generation systems [3, 8, 10, 15, 18] just in time compilers [4, 7, 12] and executable code rewriters [14, 21, 24] need to con tain a representation of how machine instructions are encoded. For example, a JIT needs to know that the x 6 instruction addl ecx, ebx corresponds to the bits 0x01cb (formed by a bitwise OR of the addl opcode 0x01c0 with 0x for the ecx argument and 0x3 for the ebx argument) ....

J. R. Larus and T. Ball. Rewriting executable files to measure program behavior. SPE, 24(2):197-218, feb 1994.

....The trace is later exposed to a cache simulator before miss correlations are reported [22] This approach shares its goal of cache correlation with our work, and we are considering collaborative efforts. CProf [19] is a similar tool that relies on post link time binary editing through EEL [17, 18] but cannot handle shared library instrumentation or partial traces. Lebeck and Wood also applied binary editing to substitute instructions that reference data in memory with function calls to simulate caches on the fly [20] Our work differs in the fundamental approach of rewriting binaries, ....

J. R. Larus and T. Ball. Rewriting executable files to measure program behavior. Software Practice & Experience, 24(2):197--218, Feb. 1994.

....cannot be resolved, we flag the basic block as having zero out edges and the graph as being an incomplete one (a non connected graph given that all the assembly code is parsed into basic blocks) for that procedure. The CFG generation technique, which has been used in RISC binary profilers like qpt [11] and in decompiling CISC code [5] is easily implemented on RISC machines due to the stylized code fragments that compilers generate for indexed jumps. In contrast, CISC code is much harder to analyse for indexed jumps. The generation of the CFG needs to remove dependencies on the hardware ....

J. Larus and T. Ball. Rewriting executable files to measure program behavior. Software -- Practice and Experience, 24(2):197--218, Feb. 1994.

....generate dynamic statistics for any program that runs on a MIPS processor. It works by annotating executable object code with additional instructions that collect the dynamic information during run time. Dinero IV [2] is a trace driven uniprocessor cache simulator for memory reference. QPT [4] [5] is profiler and tracing system. It rewrites a program s executable file (a.out) by inserting code to record the execution frequency or sequence of every basic block or control flow edge. From this information, another program QPT STATS can calculate the execution cost of procedures in the ....

J. R. Larus and T. Ball. Rewriting Executable Files to Measure Program Behavior. Software Practice & Experience, 24(2):197--218, Feb 1994.

....to be flawed; when binary patching, SLIC replaces several instructions with a jump to the extension, making it susceptible to a race condition when some kernel thread is executing within the code being modified (see Section 4.3) 2.1. 3 Static Instrumentation Static binary rewriters such as EEL [53, 54], Rational s Object Code Insertion [76] Pixie [88] ATOM [95] and Etch [78] provide fine grained instrumentation of user programs (and potentially of kernels) Static rewriting is performed on the executable file before the program is run. In the context of a kernel, a reboot is necessary ....

.... case, from the instrumentation point, to a springboard, to the code patch, and back to just after the instrumentation point) Therefore, it is possible to achieve fine grained instrumentation with no branch or jump overheads heretofore an advantage exclusive to static instrumentation 68 systems [53, 54, 76, 78, 88, 95]. The code replacement itself uses a branch (from the entry of the old function to the replacement function) however that overhead can often be eliminated when code replacement also patches statically identifiable call sites to directly call the new function. 4.6.4 Improvements to Code ....

J.R. Larus and T. Ball. Rewriting Executable Files to Measure Program Behavior. Software--- Practice & Experience 24, 1 (February 1994).

....cannot be resolved, we flag the basic block as having zero out edges and the graph as being an incomplete one (a non connected graph given that all the assembly code is parsed into basic blocks) for that procedure. The CFG generation technique, which has been used in RISC binary profilers like qpt [14] and in decompiling CISC code [7] is easily implemented on RISC machines due to the stylized code fragments that compilers generate for indexed jumps. In contrast, CISC code is much harder to analyse for indexed jumps. The generation of the CFG needs to remove dependencies on the hardware ....

J.R. Larus and T. Ball. Rewriting executable files to measure program behavior. Software -- Practice and Experience, 24(2):197--218, February 1994.

....abstract view of the program s binary; the tool uses this interface to manipulate the instructions. These systems provide interfaces to the debugger symbol tables but do not provide any hooks for other high level information. In prior work [104] we showed how to extend a predecessor of EEL, QPT [71, 8], so that it could take advantage of some primitive high level information provided by the compiler to measure the overhead of garbage collection. 9.1.4 Summary Systems for doing whole program optimizations are one of three kinds: optimizations before linking, optimizations during linking, and ....

Larus, J. R. and Ball, T. Rewriting executable files to measure program behavior. Technical Report Wis 1083, University of Wisconsin, Mar. 1992.

.... an indirect jump cannot be resolved, we flag the basic block as having zero out edges and the graph as being an incomplete one (a non connected graph given that all the assembly code is parsed into basic blocks) The CFG generation technique, which has been used in RISC binary profilers like qpt [11, 2] and in decompiling of CISC code [5] is easily implemented on RISC machines due to the stylized code fragments that compilers generate for indexed jumps. In contrast, CISC code is much harder to analyse for indexed jumps. The generation of the control flow graph removes dependencies on the ....

....The new basic block is needed in case other instructions jump to the target address directly, and may be removed later on in the analysis if no other basic block transfers control to it. This technique has been used in the past in binary profilers like qpt, and are explained in detail in [11]. In our framework, the removal of delayed instructions is just another machine idiom. High Level Opcodes Assembly mnemonic instructions can be represented by a set of five different high level opcode instructions: ffl assignment ( assigns the right hand side expression to the left hand ....

J.R. Larus and T. Ball. Rewriting executable files to measure program behavior. Software -- Practice and Experience, 24(2):197--218, February 1994.

....replaces the system serverepilog: machinestack = userstack; restoreuserregisters( returnaddress = userreturn; return; Figure 6: Server Epilog 7 supplied code. The special code can be inserted in the executor during the linking of the user program or by directly modifying the executable [16]. The start up code sets up relevant signal handlers, interprets the command line, and initializes server s variables. Because the command line is shared between the user program and the directing server, a dedicated marker is used to distinguish server s arguments from user s arguments. After ....

J. R. Larus and T. Ball. Rewriting executable files to measure program behavior. Software--Practice and Experience, 24(2):197--218, February 1994.

....Instrumentation to precisely count and time events is inserted by dynamically modifying the binary program. A more static approach is a technique that reads an executable file and then generates a modified one with tracing inserted. This technique is used in tools such as Quantify [7] and qpt [5]. Quantify and qpt operate on static binaries whereas Dynamic Instrumentation modifies binaries on the fly. Several trace based tools have been designed for performance tuning parallel applications, such as Pablo [8] AIMS [11] and IPS 2 [6] These systems require an application to be ....

J. R. Larus and T. Ball, "Rewriting Executable Files to Measure Program Behavior", Software---Practice & Experience 24, 2 (Feb, 1994), pp. 197-218.

....Section 4.2 states our assumptions and argues that they are reasonable. Section 4.3 describes and characterizes the benchmark programs used in this study. Section 4.4 describes the metrics used to present memory subsystem performance. 4. 1 Tools We extended QPT (Quick Program Profiler and Tracer) [33, 9, 32] to produce memory traces for SML NJ programs. QPT rewrites an executable program to produce compressed trace information; QPT also produces a program specific regeneration program that expands the compressed trace into a full trace. Because QPT operates on the executable program, it can trace ....

Larus, J. R., and Ball, T. Rewriting executable files to measure program behavior. Tech. Rep. Wis 1083, Computer Sciences Department, University of Wisconsin-Madison, Mar. 1992.

No context found.

J. R. Larus and T. Ball. Rewriting executable files to measure program behavior. Software Practice and Experience, 20(2):197--218, February 1994.

No context found.

J.R. Larus and T. Ball. Rewriting executables files to measure program behavior. Software - Practice and Experience, 24(2):197--218, 1994.

No context found.

J. R. Larus and T. Ball, Rewriting executable files to measure program behavior, Technical Report 1083, Dept. of Computer Science, University of Wisconsin, March 1992.

No context found.

J. Larus and T. Ball. Rewriting executable files to measure program behavior. Software Practice and Experience, 24(2):197--218, 1994.

No context found.

Larus, J. R., and Ball, T. Rewriting Executable Files to Measure Program Behavior. Software Practice & Experience 24, 2 (Feb 1994), 197-218.

No context found.

J. R. Larus and T. Ball, Rewriting executable files to measure program behavior, Technical Report 1083, Dept. of Computer Science, University of Wisconsin, March 1992. The paper analyzes the qp and qpt profiling tools, and discuss how the tools could be modified to improve perfoormance. 4

No context found.

J.R. Larus and T. Ball. Rewriting executables files to measure program behavior. Software - Practice and Experience, 24(2):197--218, 1994.

No context found.

J. R. Larus and T. Ball. Rewriting executable files to measure program behavior. Software---Practice and Experience, 24(2):197--218, February 1994.

No context found.

J. R. Larus and T. Ball, "Rewriting Executable Files to Measure Program Behavior" Software---Practice and Experience 24(2), 197--218, Feb. 1994.

No context found.

J. R. Larus and T. Ball, `Rewriting executable files to measure program behavior', Software -- Practice and Experience, 24(2), 197--218 (1994).

No context found.

J. R. Larus and T. Ball, `Rewriting executable files to measure program behavior', Software--Practice and Experience, 24(2), 197--218 (1994).

No context found.

J. R. Larus, T. Ball, "Rewriting Executable Files to Measure Program Behavior", University of Wisconsin-Madison, Computer Science Technical Report 1083, March 1992, to appear in Software Practice & Experience.

First 50 documents  Next 50

Online articles have much greater impact   More about CiteSeer.IST   Add search form to your site   Submit documents   Feedback  

CiteSeer.IST - Copyright Penn State and NEC