Patent Application
20140344789
This disclosure relates to debugger operations. In particular, it relates to a debugger step function at the machine code level.
A function, also known as a procedure, routine, or subroutine, is a sequence of instructions that perform a specific operation. Functions may be used to simplify a program by breaking parts of the program into simple steps and eliminating redundancy in codes. A calling routine gives control of the program to the function, passes variables into the function, and receives a result from the function. To call a function, the calling routine may contain a collection of instructions that branch to the function and specify the return address back into the calling routine after the function has executed.
A method for implementing a step over operation by a debugger for an instruction in a routine includes receiving a step over command for an instruction and determining whether the instruction is a branch used for a function call. If the instruction is not a branch used for a function call, then the debugger treats the instruction as not a function call. If the instruction is a branch used for a function call, then the debugger determines whether the instruction is generated from source code. If the instruction is not generated from source code, then the debugger treats the instruction as not a function call. If the instruction is generated from source code, then the debugger treats the instruction as a function call.
The drawings included in the present application are incorporated into, and form part of, the specification. They illustrate embodiments of the present invention and, along with the description, serve to explain the principles of the invention. The drawings are only illustrative of typical embodiments of the invention and do not limit the invention.
When source code created by a user calls a function, a compiler translates the function call into machine code according to a linkage (or call) convention. The linkage convention includes instructions for the function call of the calling routine, the prolog of the function, and the epilog of the function. The function call of the calling routine may include setting up the function, defining parameters and storage addresses, and branching to the function. The prolog of the function may include setting up the stack frame, storing the current register values in a save area, and preparing registers for the function's operations. The stack frame for the function contains information relating to the function, such as parameters, variables, and the program's return address. The body of the function contains the instructions of the function and corresponds to source code. The epilog of the function may include saving the result of the function, taking down the call stack frame, restoring the registers to their previous state before the function was called, and branching to the return address of the calling routine.
Debuggers for software programs allow a user to evaluate code in the program by setting a breakpoint in the program, executing one or more instructions up to the breakpoint, and analyzing register values and the program's instruction stacks. To simplify its operations and user interface, a debugger will commonly have step commands to navigate through lines of source and machine code in a program. These step commands allow a user to execute the program instruction by instruction (machine code) or statement by statement (source code).
A debugger may have different step commands for navigating a called function within a routine. If a user is interested in evaluating the instructions of the called function, the user can “step into” the function using a “step into” command. For a “step into” operation, the debugger may set a breakpoint on the next instruction of the calling routine as well as the first instruction of the called function. The user may then walk through each instruction of the called function, eventually returning from the function and stopping at the breakpoint. If the user is not interested in the called function's operation or is only interested in the values returned by the function, the user can “step over” the function. For a “step over” operation, the debugger may only set a breakpoint on the next instruction of the calling routine and the called function will execute in its entirety through to the breakpoint without stopping in the function. In this way a user can more efficiently debug a program using the debugger's interface.
Debuggers may perform step commands on the source code or on the machine code. For example, the dbx debugger may evaluate source code with a “step” command that steps into a called function and a “next” command that steps over the called function, as well as other step commands for stepping out of a function once in the called function. Similarly, dbx may evaluate machine code with a “stepi” command that steps into a called function and a “nexti” command that steps over a called function.
At the source code level, when a debugger performs a “step over” command on a statement, the debugger evaluates whether the statement is a call to a function. The debugger may evaluate the statement in its entirety, which may include multiple machine instructions generated by a compiler according to a specific linkage convention. A debugger that is aware of the way in which the compiler generates machine code from source code may make assumptions about the source statement's character to determine whether the statement is a function call. For example, in a call convention of an IA-32 architecture utilizing a call stack, a call to a function involves pushing a return address for the program's instruction pointer onto the call stack and jumping to the function. In this linkage convention context, a debugger is able to determine whether the source statement is a function call. Other debuggers may rely on the depth of the call stack for assurance that execution has entered a subroutine when stepping a source line. If a step over command is given, these debuggers simply execute the program until the stack depth is equal to where it started.
At the machine code level, a debugger may not have the same context for identifying whether a machine instruction is a function call as the debugger may when evaluating source code. A debugger will likely not be able to detect a change in the stack depth after executing the jump instruction associated with the call. As illustrated in
Referring to
Additional problems may occur when stepping over recursive routines, as the return point may be encountered many times before the actual return from the instance of the routine being stepped over occurs. This requires that the stack depth be checked to know when the actual stepped over instance of the routine completes. On many systems, such as IBM's zSeries, the stack depth is established in the prolog and epilog. If the user is machine stepping through the epilog or prolog and tries to do a step over operation on a branch that looks like a call, the stack depth is not realizable and can lead to unpredictable behavior. The inability to use stack depth information for machine step operations leads to awkward support for recursive routines.
According to embodiments of the invention, a debugger may selectively perform a step over operation on an instruction by evaluating the instruction in the context of its source. As discussed above, a machine instruction has less information than a source statement for the debugger regarding whether the instruction is a function call. However, a debugger is able to make more assumptions about machine code generated by a compiler from source code than machine code that is not generated by a compiler from source code. A branch instruction for a function call may be generated directly from source code while other parts of the code, such as the prolog and epilog of a function, are generated from the linkage convention for the instruction set. A compiler may generate debug information regarding the source of the machine instructions, so that a debugger may determine whether a machine instruction has been generated from source code.
When a step over command is invoked for a branch instruction, the debugger may evaluate whether the branch instruction can be used for a function call. If the instruction can be used for a function call, the debugger evaluates whether the branch instruction is generated from source code. If the instruction is not generated from source code, the debugger cannot be sure that the branch instruction will be used for a function call. If the instruction is generated from source code, then the debugger can determine, with greater certainty, that the branch instruction will be used for a function call. By restricting a debugger's treatment of perceived function calls to only those branches that are both used for function calls and have been generated from source code, a debugger may more accurately classify and handle a branch instruction in a step over operation, and may also be able to use the stack depth to ensure stopping at the return of the called instance of the routine since the stack depth is always defined within generated code.
According to embodiments of the invention, a debugger may determine whether an instruction has been generated from source code by utilizing debug information that includes relational information of machine instructions and source code. When a compiler creates an executable program, it may generate debug information used to later debug the program. This debug information may include source line mapping, symbol tables, and other source information that relates to machine instructions generated by the compiler. Source line mapping maps machine instructions to particular lines of source code from which they are generated. For example, in
If the debugger identifies the instruction as a branch instruction, the debugger may determine whether the instruction may be used as a function call. The debugger may look up the instruction in a call table that contains branch instructions that may be used for function calls, as in 304. The call table may be a table of instructions used to implement a call. The debugger may determine whether the instruction is present in the call table, as in 305. If the instruction is not present in the call table, the debugger may treat the instruction as a branch that is not a function call by setting a breakpoint at the next instruction in the routine (for if the branch is not taken) and setting a breakpoint at the branch target instruction (for if the branch is taken), as in 306.
If the instruction is present in the call table, the debugger may determine whether the instruction has been generated from source code, as in 204. The debugger may look up the source line mapping of the instruction in the debug information generated by the compiler, as in 307, and determine whether the instruction maps to a line of source code, as in 308. The source code mapping may be present in the debug information as a debug information entry, following a debug information format such as DWARF.
If the debugger determines that the instruction does not map to a line of source code, the debugger may treat the instruction as a branch that is not a function call by setting a breakpoint at the next instruction and setting a breakpoint at the branch target instruction, as in 306. If the debugger determines that the instruction does map to a line of source code, the debugger treats the instruction as a function call by setting a breakpoint only at the next instruction. In the
According to embodiments of the invention, a debugger that utilizes debug information to evaluate function calls may support recursive routines in programs using software stacks. Because debug information is known for an instruction used for a function call, debug information for that instruction may be accessed to determine the stack depth when the breakpoint for the step over operation is set. By saving a starting stack depth and evaluating an instruction with respect to the saved starting stack depth, the debugger may allow recursive routines in architectures that rely on software stacks, as the debugger may have call frame information to determine the stack depth.
After setting the breakpoint and saving the starting stack depth, the program executes, as in 402. The program continues to execute, as in 403 and 404, until a breakpoint is encountered. Once a breakpoint is encountered, the debugger determines whether the current stack depth is greater than the saved stack depth, as in 405. In stacks that populate from the top to the bottom, the debugger would evaluate whether the current stack is less than the saved stack depth. If the current stack depth is greater than the saved stack depth, the program executes the next instruction, as in 404, and continues to run. If the current stack depth is not greater than the saved stack depth, then the program stops at the breakpoint, as in 406.
Although the present disclosure has been described in terms of specific embodiments, it is anticipated that alterations and modifications thereof will become apparent to those skilled in the art. Therefore, it is intended that the following claims be interpreted as covering all such alterations and modifications as fall within the true spirit and scope of the disclosure.
