Tdb: A Source-level Debugger for Dynamically Translated Programs

Transcription

1 Tdb: A Sorce-level Debgger for Dynamically Translated Programs Naveen Kmar, Brce R. Childers, and Mary Lo Soffa Department of Compter Science University of Pittsbrgh Pittsbrgh, Pennsylvania {naveen, childers@cs.pitt.ed Department of Compter Science University of Virginia Charlottesville, Virginia soffa@cs.virginia.ed Abstract Debgging techniqes have evolved over the years in response to changes in programming langages, implementation techniqes, and ser needs. A new type of implementation vehicle for software has emerged that, once again, reqires new debgging techniqes. Software dynamic translation (SDT) has received mch attention de to compelling applications of the technology, inclding software secrity checking, binary translation, and dynamic optimization. Using SDT, program code changes dynamically, and ths, debgging techniqes developed for statically generated code cannot be sed to debg these applications. In this paper, we describe a new debg architectre for applications execting with SDT systems. The architectre provides featres that create the illsion that the sorce program is being debgged, while allowing the SDT system to modify the execting code. We incorporated this architectre in a new tool, called tdb, that integrates a SDT system, Strata, with a widely sed debgger, gdb. We evalated tdb in the context of a code secrity checker. The reslts show that a dynamically program can be debgged at the sorce level and that the approach does not overly increase the rn-time performance or memory demands of the debgger. Categories and Sbject Descriptors D.2.5. [Software Engineering]: Testing and Debgging Debgging aids; D.3.3. [Programming Langages]: Langage Constrcts and Featres Program instrmentation, rn-time environments General Terms Langages, Performance, Algorithms Keywords Debgging, Dynamic Binary Translation, Dynamic Instrmentation 1 Introdction Althogh the importance of debgging techniqes to assist sers in finding software bgs has long been recognized, new debgging techniqes contine to be needed as programming langages, ser demands, and implementation strategies change. The goal of a debgger is to accrately respond to ser qeries and commands Permission to make digital or hard copies of all or part of this work for personal or classroom se is granted withot fee provided that copies are not made or distribted for profit or commercial advantage and that copies bear this notice and the fll citation on the first page. To copy otherwise, or repblish, to post on servers or to redistribte to lists, reqires prior specific permission and/or a fee. AADEBUG 05, September 19 21, 2005, Monterey, California, USA. Copyright 2005 ACM /05/0009$5.00. from the viewpoint of the sorce program. Debgging activities inclde reqesting variable vales, single stepping throgh program exection, watching for particlar conditions and reqests to add and remove breakpoints. In order to respond, the debgger has to map the vales and statements that the ser expects sing the sorce program viewpoint, to the actal vales and locations of the statements as fond in the exectable program. As programming langages have evolved, new debgging techniqes have been developed. For example, checkpointing and time stamping techniqes have been developed for langages with concrrent constrcts [6,19,30]. The pervasive se of code optimizations to improve performance has necessitated techniqes that can respond to qeries even thogh the optimization may have changed the nmber of statement instances and the order of exection [15,25,29]. Crrently, a new implementation vehicle, software dynamic translation (SDT), is being increasingly sed for important applications, inclding software secrity [17,22], dynamic code optimization [1,2,4], binary translation of one instrction set to another [10,11,12,23], host machine virtalization [28], and compter architectre simlation [8,28]. A SDT system translates (generates) target code fragments/traces dynamically and stores the generated code in a fragment cache from which it exectes. Trampoline code is pt in the code to switch between the fragment cache and the dynamic translator for code generation. A SDT system may also insert instrmentation code into a program to gather rn-time information and monitor program behavior. The motivation to debg dynamically programs arises from two sorces. First, some environments may have a dynamic translator tightly integrated with the host machine sch that all applications mst be before exection. Therefore, a developer may not have the lxry of debgging the application withot dynamic translation. Secrity systems enforcing secrity policies by checking an application s binary code fall in this category [5]. Secondly, SDT systems may reslt in code transformations that expose bgs that are not manifested in the absence of the transformation. An example in this category is a dynamic optimizer [1,2,4]. SDT creates problems in debgging that cannot be solved by crrent techniqes. In particlar, debggers targeted for statically generated code prodce debg information at compile-time. The debg information consists of mappings that can be sed to relate sorce code and data to the exectable. Since the target code is generated dynamically, this static debg information for relating the code statements and data vales to the execting code, is insfficient. Another problem is that a statement can be modified dring exection, or a statement may be several times sch that the nmber of statement instances can change throghot exection. Yet another problem that crrent techniqes cannot handle is a ser may pt a breakpoint, sing the sorce program, in code that has not been yet. Solving 123

2 these problems reqires techniqes that can relate the sorce code to the execting code, as the code is dynamically generated and modified. In SDT systems, the trampoline code, as well as instrmentation code, is exected as part of the application code. However, this code shold be transparent to the ser debgging the application. Similarly, the translation actions shold also be hidden from debg sers. Therefore, debgging techniqes need to be developed that hide exection of everything that is nrelated to sorce code. Finally, de to both the growing importance of SDT and the difficlty of developing SDT systems, several frameworks, inclding Strata [21], Dynamo/RIO [4], and Walkabot [7], have attempted to enable dynamic translator reconfigrability and retargetability to ease the brden of SDT development. As a reslt, the SDT system can easily be targeted to a different SDT application or machine platform. Hence, there is a strong need to decople the debgger as mch from the SDT system as possible, so that debgging capabilities can be qickly realized for a new SDT system. In this paper, we present a new debg architectre for SDT systems that achieves transparency while spporting the sal sorcelevel debg qeries inclding step, watch, and set and remove breakpoints. The debg architectre also provides necessary decopling between the SDT system and the debgger. This paper provides a reference implementation of the debg architectre. The dynamic code changes that we consider reslt from basic translations, overhead redction transformations, and dynamic instrmentation. The basic dynamic translations inclde generating a new instrction, inserting mltiple instrctions for a single program statement dring translation, ignoring and not generating instrctions for a program statement, deletion (flshing) of previosly instrctions, and the dplication of program instrctions in the code. We also consider several overhead redction transformations, inclding instrction trace formation, conditional branch linking, indirect branch translation caching, partial inlining of nconditional branches and calls, and fast retrn handling [21]. Finally, we consider the effect of insertion and removal of instrmentation in the code. To demonstrate the effectiveness of or techniqes, we developed a new debgger, tdb, based on or debg architectre. Tdb extends the GNU gdb debgger and spports all of gdb s sorcelevel commands and qeries. We integrated the SDT framework Strata [21] into the debg architectre and evalated the debgging capabilities in the context of a software secrity checker. This paper makes a nmber of contribtions, inclding: A debg architectre that enables sorce-level debgging for dynamically programs and an implementation of this architectre in a new tool, tdb; An interface that enables SDT debgging tools to be easily written withot regard to machine specific details and SDT system specific details; An interface that enables existing debggers to be easily extended to spport dynamically programs; Debg techniqes that provide sorce-level transparency even thogh instrmentation and trampoline code are exected as part of the application code; Debg techniqes that handle the dynamic transformations that are sed to redce translation overhead by avoiding context switches; and, A verification and experimental evalation that shows or approach works well and has minimal overhead. In the next section, we describe backgrond and the challenges of debgging dynamically programs. Section 3 describes an overview of or debg architectre. Section 4 describes the components and interfaces in the debg architectre, inclding techniqes for generating and sing debg information, for a basic SDT system. Section 5 describes the generation of debg information for a more complex SDT system. Validation and experimental Context Captre New PC Context Switch Application Binary Dynamic Translator Cached? Finished? OS CPU New Fragment Fetch Decode Translate Next PC Figre 1: A software dynamic translator reslts of tdb are presented in Section 6. Finally, Section 7 describes related work and Section 8 smmarizes and concldes with ftre work. 2 Backgrond Debggers se breakpoints to enable a ser to nderstand and control a program, inclding pasing and stepping throgh exection and inspecting and modifying data vales. To answer sorce-level qeries, a debgger maps a program s sorce code to its binary exectable instrctions and data locations sing information provided by the compiler. A debgger s job is difficlt when programs are modified dynamically becase information provided by the compiler can become inconsistent with the code modifications. A SDT is an exection environment that changes code dynamically. A basic SDT system, shown in Figre 1, is a software layer between the application and the nderlying operating system. Ths, given an application s sorce program, a compiler first generates some type of code, inclding binary or a higher level representation sch as byte code. This code, which we call code, is then by the SDT to a binary exectable. Translated instrctions are held in a software cache, called the fragment cache. The cache holds code fragments (or instrction traces), which are instrction seqences that execte seqentially, ending with a conditional or indirect control transfer. The working of a SDT system is shown in Figre 1. A SDT system first captres the context of an application (e.g., PC, registers and condition codes) and saves it. Following context captre, the SDT system processes the sbseqent application code to be exected.the SDT system checks to see whether the code to be exected has been previosly and cached. If yes, a context switch restores the application context and begins execting application instrctions on the host CPU. If the code is not cached, the instrctions are fetched and one-by-one. When an instrction is, it is placed in a fragment within the fragment cache. Instrctions are ntil an end of fragment condition is encontered (e.g., a branch or an indirect jmp). A control transfer that terminates a fragment retrns control to the SDT layer throgh a trampoline becase the code at the control transfer s target may not have been yet. When translation of a fragment is complete, the SDT layer performs a context switch to the code cache for exection. Ths, the dynamic translator gets control after each fragment exectes to translate sbseqent fragments. Becase the SDT layer exectes different code than the code, the sorce-to-binary debg mappings maintained with static information are insfficient by themselves for debgging code. As an example, consider a simple translation that copies a binary instrction from the code to exactly one location in the fragment cache. We assme that the mappings from sorce to code are available from the compiler. Dring a debg session, when a ser places a break- 124

3 point at a sorce program instrction, the debgger cannot locate the instrction where the breakpoint shold actally be placed becase of the translation. One complexity of debgging an application exected with SDT involves the translation of a branch. A branch is handled with a trampoline that is sed to re-invoke the dynamic translator to translate the branch s actal target fragment(s). In a debg session, the location of the sorce branch is mapped to the branch; however, the exectable branch instrction has changed which can affect the reportability of debg qeries. When debgging a dynamically modified program with a traditional debgger, the ser has to be aware of the trampoline code and the sbseqent entry into the translator. Ths, if a ser isses a next command, he/she has to be aware that the stopping point may be the trampoline code. Another problem occrs when the translator deletes a instrction, reorders instrctions, or introdces more instances of an instrction than were in the code. Also, the nmber of instrction instances may change dring exection. In these cases, the debgger has to detect the correct instrction instance being exected. Another case happens when the dynamic translator flshes the fragment cache to free space. The debgger needs to recognize that the debg information for the flshed instrctions are no longer in effect. Even more challenging is when the translator applies overhead redction transformations. Most dynamic translators se several overhead redction transformations to avoid context switches between the dynamic translator and the code cache, inclding fragment linking, indirect branch translation caching and chaining, instrction trace formation, fast retrn handling, and partial inlining of target blocks for nconditional control transfers [2,4,11,21]. Fragment linking rewrites conditional branches to avoid invoking the dynamic translator when the code at the actal target of a branch is already. Linking two fragments reqires rewriting the existing branch to directly transfer control to the target (ths, by-passing trampoline code). If the debgger is naware of this code transformation, then it may report incorrect information abot the branch or the trampoline code. Similarly, instrctions are emitted to minimize the contextswitches into the SDT system from fragments with indirect branches [2,21]. Another overhead redction techniqe forms instrction traces, chains of code fragments, to improve cache locality and simplify branch handling. An instrction trace can be, for example, a seqence of instrctions on a hot path. Instrction traces present a challenge for a debgger becase the traces change at rn-time and incr code dplication, code flshes from the fragment cache, branch inversions and fragment linking. The debgger mst pdate its knowledge of dplication, flshes, and dynamic linking and keep these modifications transparent from the ser. The other overhead redction techniqes and dynamic instrmentation also perform code modifications that need to be tracked by the debgger. 3 Overview of the SDT Debg Architectre In this section, we describe a debg architectre that can be sed for sorce-level debgging of dynamically programs. The strctre of this architectre is shown in Figre 2. The debg architectre has three components: a SDT system, a native debgger and a debg engine. The arrows in the figre represent the invocation of one component (or an action in a repository) by another component. For example, the arrow between the native debgger and the mapper denotes initiation of operations in the mapper. The debg engine is the key component of the debg architectre, which comptes debg information at rn-time. This information is sed to hide code generation and modification in the SDT system from the native debgger. Mapping Repository Mapping Generator translation operations mapaddress writevale Dynamic Translator Native Debgger Mapper inser/delete breakpoint exceptioncallback Breakpoint Manager read/write exception Fragment Cache Breakpoint Repository DEBUG ENGINE Figre 2: SDT Debg Architectre The native debgger is similar to a conventional debgger, except that it performs debg actions by targeting the debg engine, rather than the execting program. For example, if a ser sets a breakpoint at a sorce location, the native debgger comptes the corresponding location (binary or bytecode) and notifies the debg engine to set a breakpoint at that location. This is in contrast to the traditional scenario in which the debgger wold itself set the breakpoint. The SDT system is minimally altered to commnicate the translation operations to the debg engine. The architectre does not impose restrictions on the SDT system, sch as transformations that shold not be performed in a debg session. The application being debgged needs to be compiled with the static debg flag trned on, as is traditionally done to debg at sorce level. The debg architectre does not reqire any other changes to theprogram. Debg Engine. The debg engine consists of three components: a mapping generator, a mapper, and a breakpoint manager, and two repositories, the mapping repository and the breakpoint repository. The components and repositories are shown in Figre 2. The mapping generator comptes debg information, consisting of dynamic debg mappings, to relate sorce program locations to program locations and the vice-versa. It ses information provided by the SDT system for generating and pdating mappings. The mappings are stored in the mapping repository. The mapper ses the debg information from the generator to map and code. The otpt of the mappings can be sed by either the native debgger or the SDT system. The mapper also interacts with the breakpoint manager to determine if a breakpoint needs to be placed in freshly code. The breakpoint manager keeps track of all active breakpoints (and watchpoints) for the execting program in the breakpoint repository. The native debgger commnicates information abot the breakpoints to the breakpoint manager. The breakpoint manager is responsible for inserting breakpoints in code. When breakpoints are hit in the code, the breakpoint manager is notified. To nderstand the flow of information throgh the debg engine, consider a typical debg session when a ser tries to insert a breakpoint at a sorce location. The native debgger comptes the corresponding program location and invokes the breakpoint manager. The breakpoint manager conslts the mapper to determine the corresponding locations and inserts breakpoints at each of these locations. The breakpoint manager also saves the breakpoint information in the breakpoint repository. When a breakpoint is hit in code, an exception is raised which is handled by the breakpoint manager. This handler 125

4 overrides the exception handler in the native debgger. The breakpoint manager invokes the mapper, which then ses the mapping repository to determine corresponding location. The location is passed to the native debgger with the information that a breakpoint has jst been hit at that location. 4 The Debg Engine This section describes how the debg engine orchestrates information flow between the native debgger and the SDT system. We first discss how mappings are generated. Then, we discss how the mapper and the breakpoint manager se the mappings to enable debg qeries and actions. 4.1 Generating Debg Mappings The mapping generator ses information received from the SDT system to compte debg mappings. It stores the mappings in the mapping repository. The debg architectre does not specify how the mappings are stored in the repository. The commnication from the SDT system to the mapping generator is performed throgh a set of API s, shown in Table 1. SDT systems may perform a nmber of different transformations on the generated code. For example, a dynamic optimizer may reorder statements [2]. The nmber of transformation operations performed dring dynamic translation is diverse and depends on the prpose of translation, sch as optimization, secrity checks, or binary translation, among others. While describing the API s for all of these operations is ot of scope for this paper, we discss the API s for operations performed by a basic SDT system. A basic SDT system generates code, one fragment at a time (as shown in Figre 1). There are five basic translation operations that are done in a SDT system. Other operations can be handled similarly or sing a combination of these operations. A reglar operation corresponds to the translation of one instrction to another. An API, as shown in the first row of Table 1, is sed to describe this operation. In this API, is the location, t is the location, the operation type is reglar, and the transformation is applied on code, as opposed to data. operation reglar delete many flsh trampoline API reglar(loc, Loc t, Trans code) delete(loc, Loc t, Trans code) many(loc, Loc t, Trans code) flsh(loc t, Trans code) trampoline(loc, Loc t 1, Loc t 2, Trans code) Table 1: API s for different translation operations A delete operation happens when an instrction does not reslt in any code (i.e., the instrction is deleted becase it is eliminated in the fragment cache). The second row in Table 1 shows an API that describes this operation. In this API,, represents location, t represents the location for the next instrction to be (e.g., statement location +1), the operation is delete, and the transformation is applied to code. A many operation involves an instrction that is into mltiple new instrctions. An API for this operation is shown in the third row of Table 1, which describes the case when translation of a statement leads to generation of two statements. In this example, represents the location and t is the location for the additional statement. A flsh operation evicts instrctions from the fragment cache. The API shown in the forth row of Table 1 can be sed to describe a flsh operation, in which t is a location containing the statement being flshed. Finally, a trampoline operation handles control transfers that reslt in trampoline code that transfers control from one location to another. The last row of Table 1 shows an API for a trampoline operation, in which is the branch location and t 1 and t 2 are the not-taken and taken trampoline locations. Operations that affect the location of data-vales, sch as those reslting from statement reordering in a dynamic optimizer, can be described in a similar way. Sch operations are not shown in this paper, althogh the debg architectre described above can be sed to generate debg information for these operations Dynamic Debg Mappings Before we describe the generation and pdate of mappings, we discss the different categories of mappings that are sed for debgging applications by a basic SDT system. For brevity, we do not make a distinction between an instrction and its location and se the term instrction to refer to its instrction location in the following discssion. There are for types of debg mappings: Un-to- code mapping (U-T): This mapping relates code to code. It is bidirectional; i.e., given an instrction, a corresponding instrction can be fond, and given a instrction, a corresponding instrction can be fond. A U-T mapping is notationally shown as D, where is the statement location and D is a set of locations. Translated-to- code mapping (T-T): This type relates instrctions to instrctions. It is sed when a dynamic code modification reslts in several new instrctions for one instrction. A T-T mapping is nidirectional and shown as t 1 {t 2, where t 1 and t 2 are instrctions. Translated-to- code mapping (T-U): This type relates a instrction to an instrction in the code. It is sed to map instrctions in the fragment cache that do not have a direct relationship to instrctions (e.g., as in trampoline code). This mapping is nidirectional and shown as t {, where t is a location and is a location in the code. Initially, before an statement,, is, it has the defalt U-T mapping,. Dring translation, an instrction s U-T mappings are pdated and T-T and T-U mappings are generated/pdated. An pdate modifies the destinations of a mapping. The dynamic debg mappings are generated/pdated differently based on how the code is dynamically transformed. For example, a translation of an instrction into another instrction reslts in pdate of a single U-T mapping, while the translation of an instrction to two instrctions cases the pdate of a U-T mapping and the generation of a new T-T mapping. Side effects that reslt from translation, sch as a fragment cache flsh also generate and pdate mappings Basic Translation Operations The mapping algorithms for the five basic translation operations, shown in Table 1, are described below. For each operation, an algorithm is sed to pdate and generate the dynamic mappings. In the algorithms, a mapping for a program or instrction is represented as <s>, where <s>=s R (or <s>= s R), s is an instrction and R is a set of destination instrction(s). For notational convenience, * is the set of destinations for a mapping (e.g., if <s>=s R in a U-T mapping, then *=R). The symbol is an instrction location and the symbol t is a location in the fragment cache. The normal set operators, sch as nion and difference, can be applied to the mappings. 126

5 Reglar. For this operation, the mapping generator pdates a U-T mapping for a program instrction as shown in Figre 3(a). Consider an location that is to a new location t. In this case, the U-T mapping <> is pdated to inclde the new destination t in s set of destinations (*). Figre 3(b) shows this mapping between the program instrction and location t 1. reglar(loc, Loc t, Trans code) { <> = * {t (a) Algorithm New mappings (solid lines) U-T: {t Note: is program instr. and t is the instr. (b) Example Figre 3: Reglar Operation Delete. The delete operation is shown in Figre 4(a). In this case, the U-T mapping <> for a deleted program instrction is pdated to map it to the next location t. The translation of the next logical program instrction will also be mapped to t. Hence, when a program instrction is deleted, the mapping generator maps it to the location of the following program instrction as shown in Figre 4(b). Here, is deleted and is mapped to the instrction, t, for +1. delete(loc, Loc t, Trans code) { // t is the next location and // is different than t in reglar oper. <> = * {t (a) Algorithm New mappings (solid lines) U-T: {t Note: is deleted program instr. +1 and t is the instr. for instr. +1. (b) Example Figre 4: Delete Operation Many. A translation that prodces more than one instrction ses the many operation in Figre 5(a). A T-T mapping is generated for each instrction in the seqence that does not have a corresponding location in the code. For example, if an instrction at location is into instrctions at locations t 1, t 2, and t 3, then a T-T mapping is generated for t 2 and t 3 with many(, t 2 ) and many(, t 3 ). A T-T mapping is not generated for t 1 becase the operation reglar(, t 1 ) is sed to pdate s mapping to have location t 1 as a destination. In effect, many maps the additional instrctions t 2 and t 3 to the location of the next program instrction. If the next instrction is +1, then t 2 and t 3 have mappings t 2 {(+1) and t 3 {(+1), where () gives the location of an program address. Figre 5(b) shows this case where t 2 and t 3 have been mapped to instrction, t 4, for the next logical program instrction, In the figres, a solid line shows the new mappings that reslt from the mapping algorithms. t t many(loc, Loc t, Trans code) { // t is an additional instrction; e.g., // t2 or t3 in the example (b) if (instrction() is not a branch) <t> = t {(+1) else <t> = t {Targets() New mappings (solid lines) T-T: t 2 {t 4, t 3 {t 4 (a) Algorithm (b) Example Figre 5: Many Operation Becase may be a branch, the instrctions may have two possible next logical program instrctions (i.e., the taken and not taken targets of the branch at ). Hence, when is a branch with taken and not-taken targets, +1 and +2, then t 2 and t 3 have mappings t 2 {(+1),(+2) and t 3 {(+1),(+2). In the algorithm, the many operation ses Targets() to get the set with the taken and not taken locations. The algorithm can be easily extended to the case when the branch targets are not yet : they can be handled by pdating the mappings when a target block is actally (in a way similar to backpatching, except the mappings are patched). The many operation can also be implemented sing T-U mappings, however it is more efficient to se the T-T mappings. Flsh. When a instrction is removed from the fragment cache (de to cache overflow, self-modifying code, or dynamically linked libraries), the flsh operation in Figre 6 is sed. When an instrction at location t is deleted, all mappings with t as a sorce or destination are modified. If t is in the set of destinations for a U-T or T-T mapping, then the destination sets are pdated by removing t. For mappings with t as a sorce, the destination set is set to, effectively deleting the mapping <t>. flsh(loc t, Trans code) { <> t = destination(<>) <> = * - {t <t 1 > t = destination(<t 1 >) <t 1 > = t 1 * - {t <t> = t Ø Figre 6: Flsh Operation Trampoline. The trampoline operation in Figre 7(a) is sed to generate T-U mappings for each instrction in a trampoline. For a location t in the trampoline, a mapping is generated from t to the trampoline s target (i.e., the code). In the algorithm, t 1 is a not-taken trampoline location and t 2 is a taken trampoline location. If the branch is nconditional, then only one trampoline will be generated and only one mapping will be formed. An example for the not-taken and taken trampolines is shown in Figre 7(b). Here, instrction is the branch and t is the branch at the end of the fragment. When the branch is not taken, control falls throgh to the not-taken trampoline at t 1. Hence, there is a mapping from t 1 to +1, which is the fallthrogh location in the program. Similarly, when the branch at is taken, control is transferred to t 2, which is mapped to +n (the taken target of ). If the trampoline consists of several instrctions, mappings will be generated for all of them sing the trampoline operator. +1 t 1 t 2 t 3 t 4 127

6 trampoline(loc, Loc t 1, Loc t 2, Trans code){ <t 1 > = t 1 {nottaken() <t 2 > = t 2 {taken() (a) Algorithm New mappings (solid lines) T-U: t 1 {+1, t 2 {+n 4.2 Using Mappings for Debg Qeries The native debgger commnicates debg qeries and actions to the debg engine. The API s are shown in Table 2. The debg engine ses mappings from the mapping repository to implement these qeries and actions on the code. A write operation is sed by the native debgger to write a vale into the program. All writes in the native debgger are overloaded in or debg architectre to instead call the write API. The API is shown in the first row of Table 2. In this API, represents the location to be written to; v represents the vale to be written; and s represents the size of data. Note that the location may be a memory location as well as a register. The mapaddress operation is sed by the native debgger to reqest a location for an location. Any debg action sing locations in the native debgger are overloaded in or debg architectre to call the API shown in the second row of Table 2. The address in the API call is the location. The insertbreakpoint and removebreakpoint operations are sed to insert and remove breakpoints in the code. The API s for inserting and removing breakpoints are shown in the last two rows of Table 2. In the API s, represents an location and t represents the type of breakpoint (e.g., breakpoint or watchpoint). operation (b) Example Figre 7: Trampoline Operation API write write(address, Vale v, Size s) mapaddress mapaddress(address ) insertbreakpoint insertbreakpoint(address, Type t) removebreakpoint removebreakpoint(address, Type t) Table 2: API s for different debg operations +1 +n t t 1 t 2 For each of the operations described above, the debg engine ses mappings in the mapping repository to determine code associations and implement debg actions. We now describe how debg qeries and actions can be implemented with or debg architectre. Set Breakpoint. A ser can place a breakpoint at a particlar sorce statement or a fnction call. To find where the breakpoint shold be placed, a traditional debgger ses the program s static symbol information and maps the sorce statement to the generated () code. When the breakpoint is hit at rn-time, control is transferred to the debgger, which sspends the program s exection. The ser can then set/delete breakpoints, modify program state, single step, or contine exection. For dynamically code, the native debgger maps sorce statements to code, sing the U-T mappings, and passes this information to the breakpoint manager. The breakpoint manager stores the breakpoint information in the breakpoint repository and invokes the mapper to determine corresponding locations. The breakpoint manager then inserts breakpoints at each of the locations. When new code is by the SDT system, mappings are generated and stored in the mapping repository. The mapper passes the information abot newly generated code to the breakpoint manager. The breakpoint manager looks p the breakpoint repository to determine if breakpoints need to be placed in freshly code. If so, the breakpoint manager inserts reqisite breakpoints. When a breakpoint is hit and an exception is raised in the code, it is handled by the breakpoint manager. The breakpoint manager ses the mapper to determine the corresponding location for the breakpoint location. This location is then passed to the native debgger for frther debg actions. Remove Breakpoint. This command removes a breakpoint. The native debgger calls the breakpoint manager. The breakpoint manager conslts the mapper to determine if corresponding locations exist for the breakpoint. If so, the breakpoints are removed from all these locations. The breakpoint manager also pdates the breakpoint repository. Contine. A contine command resmes exection after a breakpoint is hit. On a contine command, the debgger pts the statement in the breakpoint location. It then exectes the statement, re-inserts the breakpoint and contines normal exection. With dynamic translation, the same set of actions is taken, except the instrction is sed by the mapper when the debgger is stopped at a location. Next and Step. A next or step command cases exection to contine ntil the next sorce statement is encontered. With hardware-assisted single-step, both commands contine exection from the crrent breakpoint ntil a location is reached that corresponds to a different sorce statement. When the next command is sed in dynamically code, the debgger can contine exection ntil a code location is reached that can be mapped to a different sorce statement, sing the U-T mappings. If dring the single step command, a code location is reached that has a T-T or T-U mapping, then the mapper looks p dynamic mappings and instrcts the breakpoint manager to insert a ser-invisible breakpoint at the destinations of the mapping. Userinvisible breakpoints are sed by debggers to silently step throgh code (i.e., withot notifying the ser that a breakpoint has been hit). Exection contines and when the ser-invisible breakpoint is hit, the mapper checks to see if the next sorce statement has been encontered. Hence, the ser is naware that additional code for a many or trampoline has been exected. Withot hardware-assisted single-step, next or step set a breakpoint at the next sorce statement or all targets of a branch instrction. In this case, next and step are break commands and can be handled similarly to break. Watchpoint. A watchpoint monitors a change in a program vale. If there is hardware assistance for a watchpoint, an exception is raised when the vale in the watched location changes. This exception is caght by the debgger and the ser is notified. In or architectre, this exception is caght by the breakpoint manager. With a dynamic translator, the exception may be raised dring the exection of the translator itself or in additional code inserted by the translator (trampoline code, overhead redction code, or dynamically instrmented code). If a vale changes in sch a sitation, then the mappings are sed to determine whether exection shold be stopped. In this case, the mapper can resme exection invisibly to the ser (and the native debgger) to avoid reporting a change that shold be transparent. Withot hardware assistance, the debgger single steps ntil the vale at the watched location changes. The mappings can be sed to avoid the translator code and the additional code. 128

7 Other commands. Other commands sch as, disassembly, examining contents of a memory address or a register, setting a vale in memory or register, next instrction, step instrction, disable, post-mortem crash analysis, etc. can be implemented sing a combination of the techniqes above. 5 Overhead Redction Transformations and Dynamic Instrmentation Or reference implementation of the debg architectre targets a SDT system that performs basic translation, applies overhead redction transformations, and performs dynamic instrmentation. In this section, we describe how the overhead redction transformations and dynamic insertion/removal of instrmentation can be handled. We focs on the generation of mappings by the mapping generator. 5.1 Overhead Redction Transformations Dynamic code translations can be more complex than described in the last section, particlarly for overhead redction transformations. For example, an indirect branch may be into a series of instrctions to perform a lookp in an indirect branch translation cache (IBTC) sing the target address. When an IBTC is sed, T-T mappings are needed for the IBTC in addition to the U-T mapping for the indirect branch in the code. A more complex transformation, sch as instrction trace formation, involves a nmber of translations that affect the mappings. It ses the reglar, many, flsh and trampoline operations to generate its mappings. We describe the mapping algorithms for these two overhead redction transformations next. Mappings for other overhead redction techniqes can be generated similarly. IBTC(Loc,Loc t){ delete(, t) r (tramp()) do trampoline(, Ø, <r>) Figre 8: IBTC Translation IBTC. When an IBTC is sed, an indirect branch is eliminated and additional code is generated for a lookp into the IBTC. The algorithm that generates the mappings for the IBTC is shown in Figre 8. A U-T mapping is generated from the location of the indirect branch to the next location t sing the delete operation. The IBTC lookp code is essentially an indirect branch trampoline and T-T mappings <r> are generated with the trampoline operation with target being a register location. When the mappings are sed by the debgger, the target of the mapping can be inferred by inspecting the correct register. let head be frag starting a trace let entry be the fragment at the trace entry retranslate to create the trace insert a branch in head to jmp to entry pdate mappings to reflect the trace: <r> mappings(head) do flsh(<r>) t = branch in head fragment to entry e = first instrction in trace entry <t> = t {e Figre 9: Instrction Trace Instrction Trace. Figre 9 shows a simplified algorithm for generating the mappings for an instrction trace. When a trace is created, the instrctions in fragments that form the trace are re. Dring retranslation, mappings are generated normally for each instrction. After the trace is formed, the fragment that started the trace (the head fragment ) is changed to have a branch at the top of the fragment that jmps to the trace (the trace entry ), which in effect trns the head into a trampoline to the trace (for any existing fragments that are linked to the head). Becase the code in the head is dead after the trace is formed, all mappings associated with it are flshed. A T-T mapping is created for the branch from the head to the trace entry. 5.2 Dynamically Instrmented Code SDT systems typically monitor and gather information abot the execting program, and instrmentation code is injected in the code for sch monitoring and profiling. When debgging a dynamically program, the debgger has to ensre that instrmentation code (not part of the program) is transparent to the ser. In a way similar to the basic translation operations and the overhead redction techniqes, the debg mappings can be sed to hide the instrmentation. Instrmentation is typically injected with a probe. A probe is the code that intercepts program exection to transfer control to a monitor or profiler. Becase instrmentation can be both inserted and removed on-the-fly, fast breakpoints have been sed for probes [16]. A fast breakpoint replaces a instrction by a jmp to a breakpoint handler that does the instrmentation. Dynamic instrmentation systems, sch as Dyninst [18] se this techniqe. Note that a fast breakpoint is not related to debg breakpoints a fast breakpoint is inserted and removed for monitoring and profiling, rather than debgging; that is, it is transparent to the ser. When a new probe is inserted, the debg mappings need to be pdated to reflect the presence of the probe. Figre 10(a) shows how the mappings are affected. The insertprobe() algorithm takes the location that is instrmented,, as an inpt. A many operation is done for each instrction, r, in the probe (probe() retrns all locations in the probe at ). That is, a T-U mapping is generated from each instrction in the probe to the next location after (i.e., +1). The U-T mapping from the to its location t is kept to map the fast breakpoint at t to. insertprobe(loc, Trans code) { <r> probe() do many(<>,<r>) removeprobe(loc, Trans code) { <r> probe() do flsh(<r>) (a) Algorithms for Probe Insertion and Removal +1 t t 1 Before Probe Insertion probe (b) Example Figre 10: Probe Insertion and Removal Figre 10(b) show an example before and after a probe is inserted. In the before case, there is a mapping from program instrction to instrction t and a mapping from the program instrction +1 (the next logical instrction after ) to t 1. When a probe is inserted at t, a fast breakpoint is inserted to transfer control to the instrmentation code (indicated by j probe). Each instrction, t n t n+k, in the instrmentation code is mapped +1 j probe t 1 t n t n+k After Probe Insertion at New mappings (solid lines) after probe insertion T-T: t n t 1, t n+k {t 1 129

8 to the next instrction, +1, after. The case when a probe is inlined directly in the code can be handled similarly by the algorithm in Figre 10(a). Figre 10(b) shows only a probe that has been inserted with a fast breakpoint. Becase probes may be removed dring exection (e.g., when a conter reaches some threshold), the debg mappings shold be pdated. In this case, all the mappings associated with the instrmentation probe are flshed with the removeprobe() algorithm, as shown in Figre 10(a). Dynamic instrmentation may not always be performed with fast breakpoints. Indeed, the instrmented code can be inlined in the code. Or debg techniqes can handle sch programs, and the algorithms in Figre 10(a) still hold. 6 Evalation We developed a debgger, called tdb, for dynamically programs as a reference implementation of the debg architectre. Tdb ses the GNU debgger gdb (version 5.3) as the native debgger [24] and spports all sorce-level commands and qeries in gdb. The SDT system sed to dynamically translate applications was Strata [21]. The translation operations performed by Strata were the five basic translation operations as described in Section 4.1, overhead redction techniqes of fragment linking, IBTC, partial fnction inlining and instrction traces, and dynamic insertion of probes. The changes made to gdb involved modifying the fnctions that read/write program addresses and insert/delete breakpoints to instead target the API s shown in Table 2. The changes made to Strata were also small. The changes inclded modifying the translation loop of Strata, overhead redction techniqes, and dynamic instrmentation. We sed shared memory as a mechanism for commnication between different components of the debg engine. To validate and evalate tdb, we sed the debgger in a scenario involving a code secrity checker. A SDT code secrity checker instrments instrctions in the program binary and performs a secrity check before execting that instrction. This techniqe is sed in program secrity applications of SDT sch as Dynamo-RIO [17] and Strata [22,21]. Or code secrity checker is implemented with Strata and can enforce policies on the se of operating system calls, sing dynamic instrmentation at system call instrctions. For example, the se of file open may be restricted to not open certain files (e.g., the password file). We validated tdb to ensre that sorce-level information can be correctly reported. Tdb s performance and memory overheads for generating and sing the mappings were also evalated. 6.1 Methodology Several SPEC2000 benchmarks were sed to compare the reslts and overhead of gdb and tdb. All experiments were rn on a 500 MHz Sn Blade 100 with 256 MB RAM and Solaris 9. Strata s defalt fragment cache size of 2 MB was sed and all overhead redction transformations were enabled. In the secrity application, all system calls are instrmented. The instrmentation is done with fast breakpoints and enforces the restrictions on operating system services. We inserted ser breakpoints in the benchmarks with gdb and tdb. To find appropriate breakpoint locations that wold likely be hit, the fnctions that acconted for 90% of the exection time in each benchmark were selected to have breakpoints. Within these hot fnctions, breakpoint locations were selected at assignment, conditional, and switch statements. Breakpoints were also inserted at fnction calls, retrns, and instrmented system calls. The nmber of breakpoints varied from , with 6 13 fnctions selected per benchmark. All benchmarks were rn ntil at least 10,000 breakpoints were hit. The actal nmber of hits varied depending on the nmber of system calls that were exected. The breakpoints that were hit covered all dynamic code translations, overhead redction techniqes, and instrmentation points. 6.2 Verification To validate the operation of tdb, we ensred that it correctly mapped breakpoint locations to appropriate sorce statements. The validation compared the information reported by gdb withot dynamic translation to the information reported by tdb with dynamic translation. The validation was atomatically done by scripts that inserted breakpoints, controlled the program exection, and generated otpt at each breakpoint. The otpt from each benchmark rn for tdb and gdb was also atomatically compared. Table 3 shows the distribtion of the breakpoints that were hit for the benchmarks. The table shows the nmber of niqe breakpoints that were hit for the different types of translations. In the table, Reglar are reglarly instrctions, Cond are conditional branches, Calls are fnction calls, Indirect are register-indirect branches, and Instr is instrmented system calls. For example, in mcf, 14 niqe breakpoints on assignment statements were hit a total of 1,569 times. We checked whether gdb and tdb hit the same breakpoints, in the same order and the same nmber of times. In all cases, the same breakpoints were hit by both debggers. We also verified that the breakpoint commands in both cases reported the same information (e.g., which sorce line nmber was hit). Finally, we ensred that the programs ran sccessflly to completion when all breakpoints were disabled. 6.3 Performance and Memory To evalate performance and memory overhead, we compared the rn-times of both debggers and measred the memory reqirements of tdb. Table 4 shows the rn-times for the benchmarks nder gdb and tdb when breakpoints are inserted and hit, according to the methodology in Section 6.1. The first two table colmns report rn-time in seconds for hitting at least 10,000 ser breakpoints. As the table shows, gdb has rn-times that range from 135 to 244 seconds and tdb has rn-times from 192 to 379 seconds. Tdb incrs an additional overhead of 42% (bzip) to 110% (vortex), with an average of 63%, over gdb. This extra overhead is de to generating and sing mappings and inserting additional breakpoints in the code. We measred where tdb spends its time and fond that the overhead de to generating and sing the mappings is negligible and acconts for less than 1% of the overhead. The cost of translation and instrmentation was also negligible. The main cost is the insertion of additional breakpoints. As Table 4 shows in the third and forth colmns ( Total Breakpoints ), tdb inserts many more breakpoints than gdb. The nmber of additional breakpoints inserted is increased by 111% (bzip) to 220% (vortex), with an average increase of 141%. More breakpoints are inserted by tdb de to code dplication from fragment overlap (fragments may share code), partial inlining, and instrction traces. Tdb inserts breakpoints in the code and the code, which frther increases the nmber of breakpoints. As the table demonstrates, the amont of extra overhead incrred by a benchmark directly tracks the nmber of additional breakpoints inserted. The nmber of breakpoints is high for both debggers de to an implementation artifact. When a breakpoint is hit at rn-time, gdb and tdb remove all active breakpoints and re-insert them when exection resmes. Both implementations can be improved to remove and insert necessary breakpoints on-demand only as determined by the debg commands issed by the ser. Frthermore, in an actal sage scenario, very few breakpoints are active at once, and it has been or experience that the overhead de to breakpoint insertion is not perceivable. From these performance reslts, the rn-time overhead incrred by tdb over gdb is reasonable, given the large nmber of breakpoints inserted. 130