D.W. Wall. Systems for late code modification. In R. Giegerich and S.L. Graham, editors, Code Generation -- Concepts, Tools, Techniques, pages 275--293. Springer-Verlag, 1992.  Home/Search   Document Details and Download   Summary   Related Articles   Check

....We list some approaches here for completeness. Using microcode modification, ATUM [1] and MPTRACE [6] generate data and instruction traces and collect them for performing tracedriven simulations in the process of architecture evaluation. By modifying a fully linked executable, Pixie [29] Epoxie [25], and QPT [13] record the sequence of instructions and data references for profiling and tracing systems. There exist many general purpose modification tools for executables. OM [23] and ATOM [22] are tools running on Alpha AXP under OSF 1 for disassembling the binary into an intermediate form, ....

David W. Wall. Systems for late code modification. In Robert Gieberich and Susan L. Graham, eds, Code Genration - Concepts, Tools, Techniques, 275-293, Springer-Verlag, 1992.

....level can help to simplify the preparation of a workload program. In particular, source code for library object modules is no longer needed. Wall argues that instrumenting code at this level is only slightly more difficult because datarelocation tables and symbol tables are still available [Wall92]. An early example of this form of code instrumentation is Epoxie, implemented for the DEC Titan [Borg89; Borg90; Mogul91] and later ported to MIPS based DECstations [Chen93a] In both of these systems, slowdowns for the annotated programs ranged from about 8 to 15 and code expansion ranges from ....

Wall, D. Systems for late code modification. DEC Western Research Lab. Technical Report92/3. 1992.

....PDB) to construct the program representation. The PDB file contains procedure names, symbol table information, variable type information, etc. Vulcan can build the representation lazily and at low cost, without incurring the dynamic translation overhead of other schemes that transform executables[26]. Vulcan discovers the basic block boundaries within functions and also determines which parts of the binary are statically dead. The representation of each basic block is just a pointer to the raw bytes of the image. It also converts physical addresses to logical addresses to facilitate ....

....techniques used are address tracing, binary code modification, and simulation. Some related systems are discussed in this section. Pixie [17] started a class of basic block counting tools by inserting a fixed sequence of instructions into basic blocks to record their execution frequencies. Epoxie [26] extended the technique by using relocations to eliminate dynamic translation overheads. QPT [12] further extended the technique by reducing the number of basic blocks that need to be instrumented. Purify [9] instruments memory references to detect out of bounds memory accesses and memory leaks. ....

David W. Wall. Systems for late code modification. In Robert Giegrich and Susan L. Graham, eds, Code Generation -- Concept, Tools Techniques, pp. 275293, Springer-Verlag, 1992.

....information can be used by the compiler for profile driven optimizations, by developers to help them focus their tuning efforts on the relevant parts of the code. Architects might use profiling to determine the dynamic instruction mix of applications or their data and instruction cache behavior [75, 47]. Other tools instrument the code to examine the accuracy of branch predictions or scheduling decisions made by the compiler without the use of special hardware (such as bus monitoring systems) or simulation. A common class of tools instrument object code to obtain address traces, which help ....

....(see below) typically suffer a slowdown of a factor of 2 to 3. 25 Among the tools that have been (re )implemented with Atom are: ffl pixie. A reimplementation of a basic block execution frequency profiling tool. The profile generated by pixie is used by OM to guide some of its optimizations [69, 75]. ffl Third Degree. A memory leak detection tool. ffl Hiprof. A performance analysis tool that collects data similar to, but more accurate than, gprof. SPIKE Spike is an adaptation of OM to the Windows NT Alpha platform. Spike consists of an instrumentation part and optimization part. Both are ....

[Article contains additional citation context not shown here]

David W. Wall. Systems for late code modification. In Robert Giegerich and Susan L. Graham, editors, Code Generation - Concepts, Tools, Techniques, pages 275--293. Springer-Verlag, 1992. 163

....intermediate representation that could be interpreted directly. Only when exceeding a certain runtime threshold was the representation translated just in time to native code and optimized for speed. Several similar systems have since then been described in literature. Among them are work by Wall [Wal92], work on the SELF system [Hol94] DIGITAL s FX 32 technology [HH97] and the Morph system from Harvard [ZWG96 ] Although some of these systems perform dynamic adaptive optimizations at run time and use profiling data to improve optimization results, none of the aforementioned systems was ....

D. Wall. Systems for Late Code Modification. WRL Research Report 92/3, Digital Equipment Corporation, Western Research Laboratory, Palo Alto CA, May 1992.

....of assembler code 5 and defined registers in one instruction can be established easily, because registers do not have aliases. Therefore, determination of data dependences between register accesses is not in the scope of this paper. For memory references we have to solve the aliasing problem [26, 12]: decide whether two memory references access the same location. We have to prove that two references always point to the same location (must alias) or must show that they never refer to the same location. If we cannot prove the latter, we would like to have a conservative approximation of all ....

D. Wall. Systems for Late Code Modification. In R. Giegerich and S. L. Graham, editors, Code Generation --- Concepts, Tools, Techniques, Workshops in Computing, pages 275--293. Springer-Verlag, 1992.

....or to provide input for profile driven optimizations. Over the past decade many tools for different machines and applications have been developed. We briefly describe these tools by grouping them into three classes. The first class consists of basic block counting tools like Pixie[8] Epoxie[12] and QPT[7] that count the number of times each basic block is executed. The second class of tools are address tracing tools that generate data and instruction traces. Pixie and QPT can generate traces and can communicate to analysis routines through inter process communication. Mahler was used ....

David W. Wall. Systems for late code modification. In Robert Giegerich and Susan L. Graham, eds, Code Generation - Concepts, Tools, Techniques, pp. 275-293, SpringerVerlag, 1992. Also available as WRL RR 92/3, May 1992.

....of assembler code 5 and defined registers in one instruction can be established easily, because registers do not have aliases. Therefore, determination of data dependences between register accesses is not in the scope of this paper. For memory references we have to solve the aliasing problem [26, 12]: decide whether two memory references access the same location. We have to prove that two references always point to the same location (must alias) or must show that they never refer to the same location. If we cannot prove the latter, we would like to have a conservative approximation of all ....

D. Wall. Systems for Late Code Modification. In R. Giegerich and S. L. Graham, editors, Code Generation --- Concepts, Tools, Techniques, Workshops in Computing, pages 275--293. Springer-Verlag, 1992.

....pipeline scheduling, and the insertion of code for basic block counting and address trace generation. Code and data relocation is done as described above. Another tool, epoxie, relies on incremental linking which produces an executable containing a combined relocation dictionary and symbol table [29]. Its advantages over Mahler are that the standard linker can be used and data sections remain fixed so data relocation is not necessary. Epoxie produces address traces and block statistics. An extension of epoxie has been created by Chen which can instrument kernel level code [4] It is described ....

....with memory referencing instructions. Pixie then uses the registers exclusively as instrumentation registers holding buffer pointers and effective address calculations. They are used in instrumentation segments throughout the program without having to continually save and restore their values [29]. QPT relies on the caller save procedure register convention to scavenge instrumentation registers. QPT finds registers which were saved by the calling procedure but unused in the current procedure. This assumes that the program obeys the calling convention, and QPT tries to use symbol table ....

[Article contains additional citation context not shown here]

D. Wall, "Systems for late code modification," In Code GenerationConcepts, Tools, Techniques, Springer-Verlag, 1992, pp. 275-293.

....allocation, basic block counting and address trace generation, and instruction pipeline scheduling. Code and data relocation is done as described above. Another tool, Epoxie, relies on incremental linking which produces an executable containing a combined relocation dictionary and symbol table [18]. Its advantages over Mahler are that the standard linker can be used and data sections remain fixed so data relocation is not necessary. Epoxie produces address traces and block statistics. Since binary code is manipulated, a link time modification tool must have the use of a disassembler and ....

....if the user does not have access to the source code neither will he or she have all the object modules. 2.3 Executable Modification The third time at which code can be modified is after the objects have been compiled and linked into one executable. This is referred to as late code modification [18]. Its virtue is its ease of use. It is now trivial for the user to collect trace and other runtime information. In principle, any binary can be instrumented with such a tool without the user knowing anything about the assembly code constructs or compilation process. Also, the user need not have ....

[Article contains additional citation context not shown here]

D. Wall, "Systems for Late Code Modification," Digital Western Research Laboratory, Research Report, June 1991.

....data flow equations. We also show how to adapt liveness analysis to an environment where (assembly) code maybe handwritten and hence may not satisfy the clean control flow behavior of compiler generated code. Our approach, using so called compensation edges, is automatic while earlier proposals [16] special cased all the badly behaved functions in the standard libraries and hence could not cope with other misbehaved functions. Furthermore, we explore ways to improve the accuracy of liveness analysis. For a known technique involving calleesave registers we point out a possible generalization. ....

David W. Wall. Systems for late code modification. Technical Report 92/3, Digital Equipment Corporation, Western Research Lab, May 1992.

....a mechanism for user level analysis programs to control tracing. We modified process creation to initialize tracing data structures. We modified the scheduler to ensure that traced processes are inactive during trace analysis. 3.1.1. Epoxie The tracing system uses the epoxie instrumentation tool [85]. Epoxie rewrites ex 5 ecutable files, augmenting the original program text with instrumentation instructions. We extended the original epoxie tool for this project to support kernel tracing, tracing of threaded address spaces, and to reduce the growth of instrumented program text. Epoxie ....

David W. Wall. Systems for Late Code Modification. In Code Generation --- Concepts, Tools, Techniques, Springer-Verlag, 1992, pp. 275-293.

....overhead and high quality for statistical profiles. We discuss related work in Section 5, and Section 6 concludes. 2. Characteristics of Statistical Profiles In current practice, the profiles used for PBOs are typically generated using an instrumentation system [Smith 1991, Wall and Powell 1987, Wall 1992, Srivastava and Eustace 1994] Instrumentation code is added to the original executable so that it can produce a record of the program activity when the program is executed. The key property of this type of profile generation is that it can capture a complete profile including all application ....

....collection of C and Fortran programs. It is not clear if their techniques could be applied to optimizations such as procedure layout. We are currently exploring this question. Many instrumentation tools have been used to generate complete profiles for PBOs [Smith 1991, Srivastava and Eustace 1994, Wall 1992, Wall and Powell 1987] Ball and Larus [1994] discuss efficient techniques for collecting complete profile data. A good review of instrumentation tools is given by Pierce et al. 1995] Even with efficient techniques, the overhead of these tools is orders of magnitude greater than that of MCMS. ....

D. Wall. "Systems for Late Code Modification," In Code Generation --- Concepts, Tools, Techniques, Springer-Verlag, pp. 275-293, 1992.

....does not provide. Techniques based on program instrumentation have also been used in optimizations [31, 32] However, most of the tools that have been developed using program instrumentation techniques are used for studying program or system behavior. Tools such as QPT [18] Pixie [28] and Epoxie [33] generate address traces and instruction counts by rewriting program executables. MPTRACE [13] and ATUM [1] generate data and instruction traces, and PROTEUS [5] and Shade [7] emulate other architectures. Also, software testing and quality assurance tools that detect memory leaks and access errors ....

David W. Wall. "Systems for Late Code modification." In Robert Giegerich and Susan L. Graham, eds., Code Generation -- Concepts, Tools, Techniques, pages 275-293, Springer-Verlag, 1992.

....tools is that Morph is designed specifically for automatic profiling and optimization. Morph applies profile driven, machine specific optimizations to intermediate representations of programs and libraries. Like Morph, three prior systems from Digital Equipment Corporation (Mahler [WP87] Epoxie [Wal92], OM [SW92] also performed optimizations on programs after compilation. These tools were designed for UNIX systems and required either an intermediate form representation of the program or an executable that includes relocation information. More recent systems for Windows NT include Spike [CL96, ....

D. Wall, "Systems for Late Code Modification." In Code Generation -- Concepts, Tools, Techniques, Springer-Verlag, pages 275-293, 1992.

.... in an object oriented environment; Morph , a project developed at Harvard University [Zhang et al. 1997] and the system described by the authors of this paper [Kistler 1997; Kistler and Franz 1997] Other projects have experimented with optimization at link time rather than at runtime [Wall 1992]. At link time, many of the problems described in this paper are non existent. Among them the decision when to optimize, what to optimize, and how to replace code. However, there is also a price to pay, namely that it cannot be performed in the presence of dynamic loading. Common to the ....

Wall, D. W. 1992. Systems for Late Code Modification. Technical Report 92/3 (May), Digital Equipment Corporation, Western Research Laboratory.

....binaries by inserting instructions to check memory accesses. Lee and Zorn [LZ97] have implemented the Bytecode Instrumentation Tool (BIT) for instrumenting Java byte codes with profiling tools by making changes to the existing class files on disk. Other examples include QPT [LB94] and Epoxie [Wa92]. These methods all modify existing object code. In this case, the user needs to run a tool applying the changes after every recompile. This is added work for the programmer, who must keep track of out of date classes and change specifications, and possibly maintain a separate repository of ....

David W. Wall. Systems for Late Code Modification. In Code Generation --- Concepts, Tools, Techniques, ed. Robert Giegerich and Susan L. Graham. Springer-Verlag, 1992.

....a serious problem in extensible Web environments since upload time is on the time critical path. Binary Rewriting Code instrumentation through rewriting of binaries has been used for various purposes: emulation, tracing and debugging, profiling and optimization. Tools and toolkits such as Epoxie [38], Pixie [34] and QPT [25] are designed to rewrite programs so that the modified code generates address traces and instruction counts. Generating address and instruction traces is handled by ATUM [1] which allows for detailed post mortem tracing. Emulation of other architectures is the domain of ....

....A detailed summary of binary code rewriting tools and techniques can be found in [27] The importance of Java bytecode transformation has been recognized by other research groups recently. For instance, several recent projects rely on bytecode rewriting to provide increased levels of security [20,38]. Publications on BIT [27] and JOIE [7] utilities contain a detailed list of issues that need to be solved when designing such bytecode rewriting tools. Overheads reported in [27] are evidence that Java bytecode rewriting is extremely performance sensitive. CURRENT STATUS AND FUTURE WORK The ....

Wall, D. Systems for Late Code modification. In Robert Giegerich and Susan L. Graham, eds., Code Generation -- Concepts, Tools, Techniques, SpringerVerlag, 1992.

....procedures which are called closely in time are placed close together in space. In Section 4.2 we look at the merits of using one measure over the other. 3 Methodology We use traces from code running on DECStation 5000 200 machines under Ultrix 4. 2 using the Epoxie tracer from DEC WRL and CMU [Wall 92] The traces contain both user and system references. The benchmark suite for this study is shown in Table 1. These programs are representative of a range of applications written in a diverse set of languages (i.e. Fortran, C, C , and Cecil 3 ) All these benchmarks have non negligible miss ....

Wall, D. W. Systems for Late Code Modification, pages 275--293. Springer-Verlag, 1992.

....the object module level can help to simplify the preparation of a workload. In particular, source code for library object modules is no longer needed. Wall argues that annotating code at this level is only slightly more difficult because data relocation tables and symbol tables are still available [Wall92]. An early example of this form of code annotation is Epoxie, implemented for the DEC Titan [Borg89; Borg90; Mogul91] and later ported to MIPSbased DECstations [Chen93] In both of these systems, slowdowns for the annotated programs ranged from about 8 to 15 and code expansion ranges from 2 to ....

Wall, D. Systems for late code modification. DEC Western Research Lab. Technical Report92/3. 1992.

....system design [23] The BACH system has been used to collect address trace on both Intel 80486 and Motorola 68030 based machines [14] To date they have not demonstrated the applicability of their system to RISC based computers. In our work we used two instrumentation tools, Mahler [34] and epoxie [35]. There are numerous other software instrumentation tools [27, 4, 13] but none to our knowledge have been used to collect address traces of operating system behavior. 3. The WRL CMU Tracing Systems 3.1. High Level Design The design of the tracing systems was motivated by the need for accurate ....

....creation was modified to initialize tracing data structures. Scheduler modifications were used to insure that traced processes are inactive during trace analysis. 3.2. Software Instrumentation This section describes the software instrumentation performed by the CMU version of a tool called epoxie [35], which was used for the traced Ultrix and Mach 3.0 systems on the DECstation. The tools used for the traced Tunix system differ in several ways; in particular they were integrated into the compiler loader system, but the overall approach is similar to that used by epoxie. Epoxie is similar in ....

David W. Wall. Systems for Late Code Modification. In Code Generation --- Concepts, Tools, Techniques, Springer-Verlag, 1992, pp. 275-293.

No context found.

D.W. Wall. Systems for late code modification. In R. Giegerich and S.L. Graham, editors, Code Generation -- Concepts, Tools, Techniques, pages 275--293. Springer-Verlag, 1992.

No context found.

D.W. Wall. Systems for late code modification. In R. Giegerich and S.L. Graham, editors, Code Generation -- Concepts, Tools, Techniques, pages 275--293. Springer-Verlag, 1992.

No context found.

D.W. Wall. Systems for late code modification. In R. Giegerich and S.L. Graham, editors, Code Generation -- Concepts, Tools, Techniques, pages 275--293. Springer-Verlag, 1992.

No context found.

Wall, D. W. Systems for late code modification. In Robert Giegerich and Susan L. Graham, eds, Code Generation - Concepts, Tools, Techniques, pp. 275-293, Springer-Verlag, 1992.

No context found.

David W. Wall. Systems for late code modification. In Robert Giegerich and Susan L. Graham, editors, Code Generation - Concepts, Tools, Techniques, pages 275--293. SpringerVerlag, 1992.

No context found.

David W. Wall, `Systems for late code modification', Technical Report WRL Technical Note TN-19, Digital Equipment Corporation, Western Research Laboratory, 1990.

No context found.

David W. Wall. Systems for Late Code modification. In Robert Giegerich and Susan L. Graham, eds., Code Generation -- Concepts, Tools, Techniques, pages 275-293, Springer-Verlag, 1992.

No context found.

David W. Wall. Systems for Late Code modification. In Robert Giegerich and Susan L. Graham, eds., Code Generation -- Concepts, Tools, Techniques, pages 275-293, Springer-Verlag, 1992.

No context found.

Wall, D. W. Systems for Late Code Modification, pages 275--293. Springer-Verlag, 1992.

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