Patent Publication Number: US-9417987-B2

Title: Advisory warning and workaround indications to user when stopped between load and store conditional instructions while using source level debuggers

Description:
FIELD OF THE INVENTION 
     The invention relates to debuggers, generally, and specifically to setting breakpoints and stepping through a program with a debugger. 
     BACKGROUND OF THE INVENTION 
     Modern computer architectures comprise multiple processors running multiple threads that may each access common memory spaces. In order to prevent these processors and threads from concurrently accessing and modifying the same data at the same time, some modern architectures, such a PowerPC, provide for placing a reserve on the memory address. A reserve allows a program code to view and update data values without jeopardizing data integrity. 
     When a reservation is not placed, and two threads each attempt to increment data in the same memory address, both threads may read the data from the address, increment the data, and then attempt to write the modified data back to the memory address. When the second thread reads from the memory address before the first thread has written its modified data back to the memory address, the first thread&#39;s modification will be lost because the second thread will overwrite the first thread&#39;s modification. Thus, data integrity is jeopardized. 
     When a reserve is used, both threads may place a reserve on the memory address after reading the data. When the second thread reads from the memory address before the first thread has written its modified data back to the memory address, the second thread&#39;s reserve invalidates the first thread&#39;s reserve. With its reserve invalidated, the first thread&#39;s write will fail, and the first thread may then retry its increment of the memory address. Thus, the increments of both threads will be applied to the data at the memory address because even though the second thread interrupted the first thread&#39;s access, the first thread may repeat its access so that both the first and second thread&#39;s increments will be applied to the data at the memory address. 
     A modern processor architecture that uses reserves is the PowerPC architecture. The PowerPC architecture provides an instruction set with the commands “lwarx” and “stwcx.” The lwarx instruction loads data from a memory address and places a reserve on that address. The stwcx instruction stores data to an address only if the reserve placed by the lwarx instruction is still intact. The sequence of loading and then storing data is known as a load-store sequence. In the PowerPC architecture, the load-store sequence may be referred to as a lwarx-stwcx sequence. Using the lwarx-stwcx sequence may ensure that no other processor or thread has modified the data between the time the lwarx instruction is executed and the time the stwcx instruction completes. 
     In addition, programs using a load-store sequence with a reserve may loop continuously until the data that was loaded and modified is successfully stored. For example, a PowerPC program using a lwarx-stwcx sequence may, when the stwcx instruction fails to store the data, loop back and attempt the lwarx-stwcx sequence again until the stwcx instruction succeeds. 
     Programs using these commands are typically debugged with the aid of a debugging program to test the program. Debugging programs provide for setting breakpoints within the program to allow the developer to observe the functioning of the program. Breakpoints will stop the execution of a program so that the developer may determine if the program is operating properly. Breakpoints may either be set manually by the developer, or breakpoints may be set automatically by the debugging program. 
     In order to set a breakpoint with a debugging program, modern debuggers will typically replace a program&#39;s instruction with a hardware interrupt or other breakpoint trap to halt the execution of the program and return control to the debugger. However, by changing the execution of the program, there is a risk that a reserve on a memory address will be lost. For example, a PowerPC processor can only place one reserve at a time. Thus, if a program places a reserve with the lwarx instruction and this program is then halted and execution is handed over to a debugger, then the process of halting and handing over execution may lose the reserve placed by the lwarx instruction such that the subsequent stwcx instruction will fail. 
     The lwarx and stwcx instruction pair enables a program code to view and update data values consistently without jeopardizing data integrity by placing a reservation for a specified memory location at the system bus level when loading data from this memory location by lwarx. Several instructions may follow the lwarx instruction until a conditional store is performed to store the updated data value onto this memory location. The load and store of a single data value is done as an atomic operation (an operation during which a processor can simultaneously read a location and write it in the same bus operation) such that any other store to this memory location on any CPU will make the reservation at this memory location disappear, stwcx will fail to store the updated data, and the update operation will be re-driven by the program code. Any hardware interruption or exception that occurs after the load reservation is set but before the stwcx instruction is executed will also remove the reservation. 
     Generally, source level debuggers (such as a dbx tool on AIX), operate by allowing the user to step one instruction at a time so that the user may view the register context and any memory update. For example, when performing a step at the lwarx instruction on the dbx tool, using the stepi or nexti subcommand, lwarx is executed, following instructions are processed, and a stop occurs at the instruction following the stwcx instruction. This stop occurs after stwcx because if a failure occurs, it occurs upon re-driving the execution back to the lwarx instruction. 
     Most debuggers implement stepping instructions by setting up a hardware exception at the end of execution of the instruction being stepped or by placing a breakpoint trap at the start of the next instruction. However, a problem occurs because the hardware prevents the stay of the load reservation placed by the lwarx instruction that was just stepped over. Therefore, the stwcx that follows will always fail, and the dbx user will step indefinitely over the instructions bounded by lwarx and stwcx. Thus, when stepi or nexti subcommand are issued in dbx, the dbx tool recognizes the current instruction as lwarx and places a breakpoint trap at the start of the instruction following stwcx and at the start of the instruction that may be encompassed by the lwarx and stwcx instruction sequence. In this way, dbx avoids stepping into any of the instructions present between the lwarx and stwcx but continues execution and stops outside of the lwarx and stwcx sequence. 
     A problem remains however, because if the user sets a breakpoint at an instruction in the middle of the lwarx and stwcx code sequence, the dbx tool has no way of detecting this. Thus, when the dbx tool is stopped at this instruction, the stwcx will fail, leaving an indefinite loop until the breakpoint is removed. 
     As such, a need exists to inform developers when stepping through programs or when setting a breakpoint in a program that the next step or breakpoint may unduly interfere with the program&#39;s execution. 
     SUMMARY OF THE INVENTION 
     A load store advisory program (LSAP) sets a breakpoint within a portion of a program, determines if the breakpoint will cause unexpected behavior, and generates a warning if it is determined that the breakpoint will cause unexpected behavior. The determination that a breakpoint will cause unexpected behavior may be triggered by the user setting a breakpoint within a load-store sequence or by the user stepping into a load-store sequence. Setting a breakpoint within a load-store sequence or stepping into a load-store sequence may cause the load-store sequence to repeatedly fail in an unexpected manner, resulting in unexpected behavior. The breakpoint may be set specifically by the user or may be a temporary breakpoint set by a debugger to facilitate the user stepping through the program. 
     The warning may be displayed to the user and may also include information regarding alternate breakpoints. The user may remove the breakpoint and replace it with one or more alternate breakpoints that are determined by the debugger to not cause the unexpected behavior. 
     These and other objects of the LSAP will be apparent to those skilled in the art from the following detailed description of a preferred embodiment of the invention. 
    
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
       The novel features believed characteristic of the invention are set forth in the appended claims. The invention itself, however, as well as a preferred mode of use, further objectives and advantages thereof, will be understood best by reference to the following detailed description of an illustrative embodiment when read in conjunction with the accompanying drawings, wherein: 
         FIG. 1  depicts an exemplary computer network. 
         FIG. 2  depicts a memory containing the LSAP and other programs. 
         FIG. 3A  is a diagram illustrating the interaction of the LSAP with a breakpoint. 
         FIG. 3B  is a diagram illustrating the interaction of the LSAP with step. 
         FIG. 4  is an application showing failure caused by break point. 
         FIG. 5  is a flow chart depicting the advisory debugging program. 
     
    
    
     DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT 
     The principles of the present invention are applicable to a variety of computer hardware and software configurations. The term “computer hardware” or “hardware,” as used herein, refers to any machine or apparatus that is capable of accepting, performing logic operations on, storing, or displaying data, and includes without limitation processors and memory; the term “computer software” or “software,” refers to any set of instructions operable to cause computer hardware to perform an operation. A “computer,” as that term is used herein, includes without limitation any useful combination of hardware and software, and a “computer program” or “program” includes without limitation any software operable to cause computer hardware to accept, perform logic operations on, store, or display data. A computer program may, and often is, comprised of a plurality of smaller programming units, including without limitation subroutines, modules, functions, methods, and procedures. Thus, the functions of the present invention may be distributed among a plurality of computers and computer programs. The invention is described best, though, as a single computer program that configures and enables one or more general-purpose computers to implement the novel aspects of the invention. For illustrative purposes, the inventive computer program will be referred to as the Load Store Advisory Program (LSAP). 
     Additionally, the LSAP is described below with reference to an exemplary network of hardware devices, as depicted in  FIG. 1 . A “network” comprises any number of hardware devices coupled to and in communication with each other through a communications medium, such as the Internet. A “communications medium” includes without limitation any physical, optical, electromagnetic, or other medium through which hardware or software can transmit data. For descriptive purposes, exemplary network  100  has only a limited number of nodes, including workstation computer  105 , workstation computer  110 , server computer  115 , and persistent storage  120 . Network connection  125  comprises all hardware, software, and communications media necessary to enable communication between network nodes  105 - 120 . Unless otherwise indicated in context below, all network nodes use publicly available protocols or messaging services to communicate with each other through network connection  125 . 
     LSAP  200  typically is stored in a memory, represented schematically as memory  220  in  FIG. 2 . The term “memory,” as used herein, includes without limitation any volatile or persistent medium, such as an electrical circuit, magnetic disk, or optical disk, in which a computer can store data or software for any duration. A single memory may encompass and be distributed across a plurality of media. Thus,  FIG. 2  is included merely as a descriptive expedient and does not necessarily reflect any particular physical embodiment of memory  220 . As depicted in  FIG. 2 , though, memory  220  may include additional data and programs such as operating system  280 . Of particular import to LSAP  200 , memory  220  may include one or more programs such as program  260  and debugger  240  with which LSAP  200  interacts. 
       FIG. 3A  is a diagram illustrating the interaction of an embodiment of LSAP  200  with a program. Program  260  is being debugged by a debugger such as debugger  240  (see  FIG. 2 ) and portion  311  is a portion of program  260  written using PowerPC instructions. Portion  311  operates to increment a value in memory. Line  301  is a label (“retry”) indicating the beginning of this portion of the code. Line  302  loads the data from memory and places a reserve on that memory address using the lwarx instruction. Line  303  modifies the value by adding “1” to the current value using the addi instruction. Line  304  attempts to store the value back to the same memory address, but only if the reserve is still intact using the stwcx instruction. Line  305  will repeat this portion of the code—by branching back to line  301 —if the stwcx instruction failed. 
     When the user sets breakpoint  312  at line  303  of portion  311  within program  260 , the debugger determines whether breakpoint  312  will likely cause unexpected behavior of program  260 . In this exemplary case, breakpoint  312  will cause unexpected behavior because it may cause an infinite loop. The infinite loop is created since the stwcx instruction will likely fail, even when it is expected to succeed. The stwcx instruction will likely fail because when breakpoint  312  halts the execution of program  260  the reserve placed by the lwarx instruction will be lost and the stwcx instruction will fail causing line  305  to branch back to line  301  and repeat portion  311 . In subsequent repetitions, breakpoint  312  will continue to halt the program removing the reserve so that the stwcx instruction may never succeed. Hence, so long as breakpoint  312  is within the load store sequence, the store will repeatedly fail, the code will loop back to execute from the beginning of portion  311 , and program  260 &#39;s execution will halt at line  303 . 
     When the debugger determines that breakpoint  312  will likely interfere with the execution of program  260 , the debugger generates warning  313 , which may be displayed to the user. Further embodiments of LSAP  200  may determine and suggest locations for one or more breakpoints before, after, or around the load-store sequence that will not cause unexpected behavior when set. 
       FIG. 3B  is a diagram illustrating the interaction of LSAP  200  with a user stepping through program  260 .  FIG. 3B  is similar to  FIG. 3A  except that instead of setting a breakpoint within program  260 , the user is stepping through program  260  and program counter  322  is pointing to line  302 . 
     When the user causes the debugger to step, the debugger determines whether these conditions may cause unexpected behavior of program  260 . In this exemplary case, stepping at line  302  will cause unexpected behavior because it may cause an infinite loop of portion  311 , much like in  FIG. 3A . The infinite loop is created since the stwcx instruction will likely fail, even when it is expected to succeed. The stwcx instruction will likely fail because stepping at line  302  places a temporary breakpoint at line  302 , which halts the execution of program  260  and causes the reserve placed by the lwarx instruction to be invalidated or lost. The stwcx instruction will fail because the reserve is lost, such that the command at line  305  will branch back to line  301  and repeat portion  311 . In subsequent repetitions, stepping through portion  311  will continue to place breakpoints that halt the program and remove the reserve so that the stwcx instruction may never succeed. Hence, so long as the user steps through the load-store sequence, the store will repeatedly fail, the code will loop back to execute from the beginning of portion  311 , and program  260 &#39;s execution will halt at line  302 . 
     When the debugger determines that the step will likely cause unexpected behavior of program  260 , the debugger generates warning  323 , which may be displayed to the user. Further embodiments of the invention may determine and suggest locations for one or more breakpoints before, after, or around the load-store sequence that will not cause unexpected behavior when set. 
       FIG. 4  is a depiction of application  400 . The reservation is made at  410  and the memory is updated at  420 .  422  is a breakpoint set at an instruction between the lwarx and stwcx. At  430  stwcx fails each time the debugger is stopped at the breakpoint. Program segment  400  is in a loop and the user is unaware of the reason for the application to loop. 
       FIG. 5  is a flow chart illustrating method steps for LSAP  200 . LSAP  200  starts at  505 . At step  510 , a user either sets a breakpoint within the program or “steps” through the program. To set a breakpoint, any number of methods may be used, as is commonly known in the art. For example, a user of a command line debugger may enter an instruction specifying the exact address within the program on which to set the breakpoint. Alternatively, a user of a graphical debugger may click on a line of code within the program that the debugger will correlate to a specific address within the program to set the breakpoint. Additionally, the user may “step” through the program. By “stepping” through the program the debugger may place a temporary breakpoint at the next line of code (or next address) and then execute the current line of code, such that the program will stop on the next line of code after executing the current line of code. A user may then “step” again, repeating the process. In this manner, the user may check the execution of every line of code to ensure proper operation of the program. 
     At step  520 , it is determined whether the breakpoint placed in step  510  will cause unexpected program behavior. This determination may be triggered by the user placing a breakpoint within a load-store sequence or by the user stepping into a load-store sequence. Setting a breakpoint within a load-store sequence or stepping into a load-store sequence may cause the load-store sequence to repeatedly fail in an unexpected manner, resulting in unexpected behavior. The load-store sequence effects a read-modify-write operation that loads data from memory, modifies the data, and then stores the data back to memory. In a system with multiple processors or threads of execution, this load-store sequence needs to be protected from concurrent access to memory. Concurrent access is where more than one processor or thread accesses the same data within a memory. Problems arise when more than one thread or processor updates the value of a data in memory at the same time, as is known in the art. A way to avoid concurrent access is to place a reserve on the memory address used by the load store sequence. By reserving the memory address, one thread or processor&#39;s update will not be overwritten by another thread or processor&#39;s update. However, a reserve may be lost if a breakpoint is placed within the load store sequence, causing the store to unexpectedly fail, even though the store should have succeeded were it not for the breakpoint. 
     At step  530 , a warning is generated when it is determined that the breakpoint set in step  510  will cause unexpected behavior of the program, as determined in step  520 . This warning may include the reason why the unexpected behavior is likely to occur. As an example with a load-store sequence on a PowerPC processor using the lwarx and stwcx instructions, the warning may indicate that the breakpoint to be placed may lose the reserve placed by the lwarx instruction such that the subsequent stwcx instruction will fail, even if it is expected to succeed. 
     At step  540 , alternate locations are determined for one or more alternate breakpoints that, when placed, will not cause the unexpected behavior as determined in step  540 . Such alternate breakpoints may be placed before, after, or around the portion of code that behaves unexpectedly. 
     At step  550 , the warning is displayed to the user. The warning may include further indications to the user for alternate breakpoints, as determined in step  540 . As an example with a command line debugger, the debugger may display the warning and suggest that the use place the alternate breakpoints as determined in step  540 . With a graphical debugger, the debugger may display a pop-up window with several clickable buttons to ascertain how the user will proceed. 
     At step  560 , the current breakpoint (determined to cause unexpected behavior) is removed from the portion of the program where it is causing unexpected behavior. By removing the breakpoint the program should behave as expected. 
     At step  570 , the alternate breakpoints are placed as selected by the user. As described above in step  550 , the user may select alternate breakpoints by issuing commands to a command line debugger or by clicking on a button of a pop-up window. 
     It is noted that while embodiments of the invention are described that use the PowerPC architecture and instructions, the invention is not so limited. As an example, a program that updates data within a database may suffer from similar unexpected behavior. In that case, instead of a load-store sequence comprising the PowerPC lwarx and stwcx instructions, the load-store sequence may be function calls to load and store data to the database. In accordance with the invention, if the debugger determines that a breakpoint set within the load-store sequence used for accessing a database may cause unexpected behavior, the debugger may generate a warning. 
     A preferred form of the invention has been shown in the drawings and described above, but variations in the preferred form will be apparent to those skilled in the art. The preceding description is for illustration purposes only, and the invention should not be construed as limited to the specific form shown and described. The scope of the invention should be limited only by the language of the following claims.