Abstract:
Systems and methods provide a debugger that debugs code using two versions of code, an optimized and a debuggable version of object code for subroutines, methods or functions. The debugger causes the appropriate version of the code to be executed depending on whether debug commands have been applied with respect to particular subroutines, methods or functions.

Description:
CROSS-REFERENCE TO RELATED APPLICATION(S) 
       [0001]    This application is a continuation of U.S. patent application Ser. No. 12/771,432 filed Apr. 30, 2010, entitled “SYSTEMS AND METHODS FOR DEBUGGING APPLICATIONS USING DUAL CODE GENERATION” which is incorporated herein by reference in its entirety. 
     
    
     LIMITED COPYRIGHT WAIVER 
       [0002]    A portion of the disclosure of this patent document contains material to which the claim of copyright protection is made. The copyright owner has no objection to the facsimile reproduction by any person of the patent document or the patent disclosure, as it appears in the U.S. Patent and Trademark Office file or records, but reserves all other rights whatsoever. Copyright ® 2009 Cray Inc. 
       TECHNICAL FIELD 
       [0003]    The embodiments of the present invention relate to software development and more particularly to debuggers for software applications. 
       BACKGROUND 
       [0004]    Development of software applications typically involve the frequent use of debuggers to analyze logical errors and other problems that occur during the execution of the application. Such debugging occurs both while the application is being developed or enhanced, and after the application has been provided (e.g., released) for general use. In order for a debugger application to present a user with accurate information and control of a running computer program, the program must have been compiled with a special debugging option. This option, for example, causes the compiler to generate a set of debugging tables with information that enables the debugger to map the low-level machine instructions of the program to the high-level source code with which the user is familiar. To make this mapping usable, the compiler generally must not re-order, or replace program instructions dictated by the user in the source code. This is in direct conflict with the optimizations that modern compilers can make in order to increase the speed and performance of the program. There are a great number of such optimizations and it is the norm for all of them to be disabled during a compilation using the debugging option. 
         [0005]    Therefore, users debugging large computer programs typically have to choose between program execution speed (compiled optimizations) and debugging efficacy (compiled debugger information). 
         [0006]    Furthermore, the program generated by compiling with such debugging options may be a significantly different program and may behave differently compared to the original program. Subtle timing windows, memory usage, and even compiler bugs may cause a change in behavior. The program may, in fact, no longer exhibit the symptom that the debugger was called upon to research. 
     
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
         [0007]      FIG. 1  illustrates example components for building and debugging software applications according to embodiments of the invention. 
           [0008]      FIG. 2  is a flowchart illustrating an exemplary method for a debugger using optimized and debuggable object code versions of subroutines. 
           [0009]      FIG. 3  is a flowchart illustrating an exemplary method for a breakpoint operation of a debugger using optimized and debuggable object code versions of subroutines according to embodiments of the invention. 
           [0010]      FIG. 4  is a flowchart illustrating an exemplary method for a breakpoint operation of a debugger using optimized and debuggable object code versions of subroutines according to alternative embodiments of the invention. 
           [0011]      FIG. 5  is a flowchart illustrating an exemplary method for a “step into” operation of a debugger using optimized and debuggable object code versions of subroutines. 
           [0012]      FIG. 6A  is a diagram illustrating a breakpoint operation of a debugger using optimized and debuggable object code versions of subroutines according to embodiments of the invention. 
           [0013]      FIG. 6B  is a diagram illustrating a breakpoint operation of a debugger using optimized and debuggable object code versions of subroutines according to alternative embodiments of the invention. 
       
    
    
     DETAILED DESCRIPTION 
       [0014]    In the following detailed description, reference is made to the accompanying drawings that form a part hereof, and in which is shown by way of illustration, specific embodiments in which the inventive subject matter may be practiced. These embodiments are described in sufficient detail to enable those skilled in the art to practice them, and it is to be understood that other embodiments may be utilized and that structural, logical, and electrical changes may be made without departing from the scope of the inventive subject matter. Such embodiments of the inventive subject matter may be referred to, individually and/or collectively, herein by the term “invention” merely for convenience and without intending to voluntarily limit the scope of this application to any single invention or inventive concept if more than one is in fact disclosed. 
         [0015]    The following description is, therefore, not to be taken in a limited sense, and the scope of the inventive subject matter is defined by the appended claims. 
         [0016]    In the Figures, the same reference number is used throughout to refer to an identical component which appears in multiple Figures. Signals and connections may be referred to by the same reference number or label, and the actual meaning will be clear from its use in the context of the description. 
         [0017]    The functions or algorithms described herein are implemented in hardware, and/or software in embodiments. The software comprises computer executable instructions on computer readable media. Non-transitory computer-readable media include tangible media such as hard drives, CD-ROMs, DVD-ROMS, and memories such as ROM, RAM, and Compact Flash memories that can store instructions. Signals on a carrier wave such as an optical or electrical carrier wave are examples of transitory computer-readable media. Further, such functions correspond to modules, which are software, hardware, firmware, or any combination thereof. Multiple functions are performed in one or more modules as desired, and the embodiments described are merely examples. A digital signal processor, ASIC, microprocessor, or any other type of processor operating on a system, such as a personal computer, server computer, supercomputing system, a router, or any other device capable of processing data including network interconnection devices executes the software. 
         [0018]    Some embodiments implement the functions in two or more specific interconnected hardware modules or devices with related control and data signals communicated between and through the modules, or as portions of an application-specific integrated circuit. Thus, the example process flow is applicable to software, firmware, and hardware implementations. 
         [0019]      FIG. 1  illustrates example components of a system  100  for building a software application according to embodiments of the invention. In some embodiments, the system includes a compiler  104  and a debugger  110 . Compiler  104  reads one or more application source code modules  102  as input and produces application  108  as output. Application  108  may include object code modules  105 - 107  that correspond to source code modules  102 . Application  108  may also include library modules or references to dynamically loaded library modules that are loaded when the application is executed. Compiler  104  may include or invoke various other components such as preprocessors, optimizers, linkers and/or loaders to complete the building of an application  108 . Source modules  102  may be in any programming language, including C, C++, C#, FORTRAN etc. 
         [0020]    Compiler  104  may be configured to produce multiple types of object code for a source code module  102 . For example, the compiler may produce both optimized object code  106  and debuggable object code  107  for subroutines (also referred to as methods or functions) within a source code module  102 . In general, optimized object code  106  will include any type of object code that is not specifically configured for debugging, and may include various levels of code optimization known in the art or developed in the future. Debuggable object code refers to object code that is intended to be used within the context of a debugger. The determination of when to generate both optimized and debuggable object code versions may be controlled by configuration files, compiler switches, user input, environment variables, default settings, etc. Further, debuggable code for a specific region (e.g., a block of code such as a loop) within a source module may be identified using compiler directives in the source code. In some embodiments, the compiler generates code for application  108  such that the optimized object code is executed as a default condition. Applications may be built that contain both debuggable and optimized versions of some routines, while other routines may exist in the application only in an optimized form. 
         [0021]    When a user desires to debug application  108 , debugger  110  is invoked, which reads application  108  to obtain debugging information and to control the execution of application  108 . Debugger  110  may modify memory locations occupied by application  108  as described in further detail below to cause the debuggable object code to be executed instead of the optimized object code. 
         [0022]    In some embodiments, the hardware execution environment for debugger  110  may be a single processor environment or a multiple processor hardware environment. There may be four, tens, hundreds, or even thousands of processors in the hardware execution environment for debugger  110 . In general, a processor may be any type of processor, including scalar processors, vector processors, central processing units or any other logic circuit that can execute instructions and manipulate data. 
         [0023]      FIG. 2  is a flowchart illustrating an exemplary method for a debugger using optimized and debuggable object code versions of subroutines. The method begins at block  202  when a compiler  104  receives source code to be compiled. At block  206 , the compiler creates both optimized and debuggable versions of object code for the subroutines and data produced from source code. In some embodiments, the compiler prevents name conflicts that would result from duplicate names in the optimized and debuggable object code versions by generating different subroutine names (also referred to as labels) for each version. For example, assume that a subroutine, method or function is named “interf” in the source code. In some embodiments, the compiler may preserve the name “interf” for the subroutine generated in the optimized object code, while generating a different name for the subroutine in the debuggable object code. In some embodiments, the different name may be generated by modifying the name from the source code. For example, a text string such as “_debug” may be appended to generate the subroutine name in the debuggable version of the object code. In the example above, this would result in the name “interf” for the optimized object code and “interf_debug” for the debuggable object code. As an alternative example, a text string may be placed at the front of the name. In some embodiments, the string dbg$ is prepended to the front of the subroutine name. In further alternative embodiments, labels for subroutines comprise symbols generated by the compiler that do not necessarily include the name or label used in the source code. 
         [0024]    After the application has been built using the object code produced by the compiler, at block  208  a debugger may read the object code, including both the optimized and debuggable versions of the object code. 
         [0025]    At block  210 , the debugger determines that a subroutine is to be debugged. This determination may be made as a result of receiving a breakpoint command or step command from a user operating the debugger. A subroutine may be determined to be debugged if a breakpoint is set at any point within the subroutine. Further, a subroutine may be debugged by instructions issued to a debugger that indicate that the debugger is to “step into” the subroutine to be debugged. Other methods of indicating that a debuggable version of code is to be executed are possible and within the scope of the inventive subject matter. 
         [0026]    If the debugger determines that the subroutine is being debugged, then at block  212  the debugger executes operations that cause the debuggable version of the object code to be executed. Further details are provided below with reference to  FIGS. 3 and 4 . 
         [0027]    Otherwise, if the subroutine is not being debugged, the optimized object code is executed at block  214 . 
         [0028]    Thus the embodiments of the invention provide an environment where an application executes optimized code and therefore runs at the fastest speed when not being debugged, while automatically substituting debuggable object code when a user is interested in debugging or studying the operation of the code or any specific portion of the code. 
         [0029]      FIG. 3  is a flowchart illustrating an exemplary method according to various embodiments for a breakpoint operation of a debugger using optimized and debuggable object code versions of subroutines. As noted above, debugger  110  may detect that a breakpoint has been set in a subroutine by receiving a breakpoint command at block  302 . 
         [0030]    In response to receiving the breakpoint command, in some embodiments, the debugger  110  sets a breakpoint in the optimized object code at block  304 . Methods for setting a breakpoint vary according to the hardware environment and operating system that is used, such methods are known to those of skill in the art. 
         [0031]    At block  306 , the breakpoint is encountered during the execution of the code. 
         [0032]    At block  308 , the debugger fields the breakpoint instruction. In response, the debugger causes the flow of control to be transferred to the debuggable object code. In some embodiment, the debugger may change the program counter to cause control to be transferred to a desired point in the debuggable object code for the program. 
         [0033]    In some embodiments, breakpoints are set in both the optimized and debuggable versions of the object code. It is possible that a user may decide to set a breakpoint in an debuggable subroutine after the subroutine has already been invoked once. For example, assume that routine “A” makes a call to routine “B”, which calls “C”, which in turn calls “B” a second time. Further assume that routine “B” has both an optimized and debuggable version of object code. During the course of debugging routine “C”, the user may have set a breakpoint such that B has already been at least partially executed by virtue of the call from “A” to “B”. Setting a breakpoint in both the optimized and debuggable versions of “B” allows the system to honor the user&#39;s request (e.g., break at routine “B”) and to follow the original path when unwinding the stack upon subroutine returns. 
         [0034]      FIG. 4  is a flowchart illustrating an exemplary method for a breakpoint operation of a debugger using optimized and debuggable object code versions of subroutines. As noted above, debugger  110  may detect that a breakpoint has been set in a subroutine by receiving a breakpoint command at block  402 . 
         [0035]    In response to receiving the breakpoint command, in some embodiments, the debugger  110  sets a breakpoint in the debuggable object code at block  404 . Methods for setting a breakpoint vary according to the hardware environment and operating system that is used, such methods are known to those of skill in the art. 
         [0036]    At block  406 , the debugger inserts a control transfer instruction such that the control transfer instruction is the first instruction executed when the optimized subroutine is invoked. The instruction presently at the location where the control transfer instruction is inserted may be saved so that it can be replaced if the breakpoint is removed. The control transfer instruction causes control to be transferred to the object code for the debuggable version of the subroutine. In some embodiments, a “jump” instruction may be used to cause control to be transferred from the optimized object code to the debuggable object code for the subroutine. Other methods for transferring control may be used in alternative embodiments, and the scope of the inventive subject matter is not limited to any particular method for changing the flow of execution of a program. For example, the debugger may change the program counter to cause control to be transferred to a desired point in the program. 
         [0037]      FIG. 5  is a flowchart illustrating an exemplary method for a “step into” operation of a debugger using optimized and debuggable object code versions of subroutines. At block  502 , the debugger receives a “step into” command. A “step into” command generally refers to a command that causes a debugger to continue execution from a subroutine, method, or function that is being debugged into a subroutine, method or function that is called by the subroutine. 
         [0038]    In response to receiving a “step into” command, at block  504  the debugger determines if there is a debuggable version of the subroutine, method or function. If so, the debugger sets the application context such that execution of the application is set to start at the debuggable version of the subroutine, method or function to be stepped into. If a debuggable version is not available as part of the application, the debugger continues execution at the optimized version of the subroutine, method or function. 
         [0039]      FIG. 6A  is a diagram illustrating an example breakpoint operation of a debugger using optimized and debuggable object code versions of subroutines, and further illustrates the operation of the method shown in  FIGS. 2 and 3 . For the purposes of the example, assume that an object code segment  601  makes calls to two subroutines, “difuse”  602  and “interf”  604 . Further, subroutines difuse and interf have been compiled such that two versions, an optimized version “A” and a debug version “B” have been generated. Thus in the example shown, the subroutine difuse has an optimized and a debuggable version of object code  602 A and  602 B respectively, and the subroutine interf also has an optimized and a debuggable version  604 A and  604 B respectively. 
         [0040]    For the purposes of the example, further assume that a breakpoint has been set in subroutine interf. In response, the debugger has inserted a break instruction  605  at the head of the optimized version of interf. 
         [0041]    As the executable code segment  601  is executed, a call is first made to the difuse subroutine. Because there are no breakpoints or other debug events for the difuse subroutine, control is transferred as shown by line  610  to the optimized version of difuse. When the subroutine ends, control is transferred back into the calling point as shown by line  612 . 
         [0042]    Later, executable code segment  601  makes a call to the subroutine interf. As noted above, interf has a breakpoint set. In this case, control first transfers to the optimized version of interf as shown by line  614 . Upon reaching the break instruction, the debugger takes control. The debugger takes actions to arrange for control of the program to continue at the appropriate point in the debuggable version of the object code, as illustrated by line  615 . For example, the debugger may alter the program counter to cause execution to resume in the debuggable version of the object code. After the debuggable version has finished execution, control returns to the executable cod segment  601  as illustrated by line  618 . 
         [0043]    Thus various embodiments provide executable code for a software application or other computer programs that can run at full speed when not being debugged, and can select portions of an application to be debugged when necessary to analyze problems. Such selective enabling of debuggable code in various embodiments allows debugging such that the application retains accurate and efficient debugger control, while also maximizing the runtime execution speed and minimizing changes in the program&#39;s behavior. 
         [0044]      FIG. 6B  is a diagram illustrating an example breakpoint operation of a debugger using optimized and debuggable object code versions of subroutines, and further illustrates the operation of the method shown in  FIGS. 2 and 4 . This example, will use the same initial object code arrangement as described above regarding  FIG. 6A . 
         [0045]    For the purposes of the example, assume that a breakpoint  608  has been set in interf debug( ) In response, the debugger has inserted a control transfer instruction  606  (in this example, a jump instruction) at the head of the optimized version of interf such that control is transferred to the debuggable version of interf, where a break instruction  608  has been inserted by the debugger. 
         [0046]    As the executable code segment  601  is executed, a call is first made to the difuse subroutine. Because there are no breakpoints or other debug events for the difuse subroutine, control is transferred as shown by line  610  to the optimized version of difuse. When the subroutine ends, control is transferred back into the calling point as shown by line  612 . 
         [0047]    Later, executable code segment  601  makes a call to the subroutine interf. As noted above, interf has a breakpoint set. In this case, control first transfers to the optimized version of interf as shown by line  614 . However, as indicated by line  616 , the jump instruction cause control to jump to the first executable line of code in the debuggable version of interf ( 604 B). Here control continues until the breakpoint instruction  608  is executed and the debugger takes control. After the debuggable version has finished execution, control returns to the executable cod segment  601  as illustrated by line  618 . 
         [0048]    Thus various embodiments provide executable code for a software application or other computer programs that can run at full speed when not being debugged, and can select portions of an application to be debugged when necessary to analyze problems. Such selective enabling of debuggable code in various embodiments allows debugging such that the application retains accurate and efficient debugger control, while also maximizing the runtime execution speed and minimizing changes in the program&#39;s behavior. 
         [0049]    The Abstract is provided to comply with 37 C.F.R. §1.72(b) to allow the reader to quickly ascertain the nature and gist of the technical disclosure. The Abstract is submitted with the understanding that it will not be used to limit the scope or meaning of the claims. 
         [0050]    In the foregoing Detailed Description, various features are grouped together in a single embodiment for the purpose of streamlining the disclosure. This method of disclosure is not to be interpreted as reflecting an intention that the claimed embodiments have more features than are expressly recited in each claim. Thus the following claims are hereby incorporated into the Detailed Description, with each claim standing on its own as a separate embodiment. 
         [0051]    The foregoing descriptions of specific embodiments of the present invention have been presented for purposes of illustration and description. The embodiments presented are not intended to be exhaustive or to limit the invention to the particular forms disclosed. It should be understood that one of ordinary skill in the art can recognize that the teachings of the detailed description allow for a variety of modifications and variations that are not disclosed herein but are nevertheless within the scope of the present invention. Accordingly, it is intended that the scope of the present invention be defined by the appended claims and their equivalents, rather than by the description of the embodiments.