The present invention relates to the field of debugging software during code development. More specifically, the present invention relates to hardware control of operations of single stepping and break point determination while debugging software running on a processor.
Software or code development is a process of referencing a specification for an intended program, writing programming statements in a source code language, then compiling, linking, and loading a final executable code file and debugging a result. A debugging process will determine if and when proper program behavior has been achieved. If the desired result is not achieved, then the entire process is iterated with updates to the source code until a debug session reveals that the code is operating with the proper behavior desired in the original specification.
A debugger can be a stand-alone application or an application that is merged into an integrated development environment (IDE) with the rest of a software development tool chain. The software development tool chain may include a source code editor, a syntactical code checker, a compiler, a linker, and a loader, which produces the executable code file. The debugger provides a plurality of views of the processor and programming environment. Each view is presented in a window when a graphical user interface (GUI) is incorporated. A window shows a source-level view in a source code editor. Other views of the processor may include a program stack, which is a data structure that contains, and saves for return, a state of the processor when a new routine is jumped to, an assembly-level view (or a machine code view), a view of a plurality of various registers, a view of the register contents to ascertain data and variable values, a debug information view generated by the compiler. With these views available throughout the operation of the processor on the program being developed, the behavior can be retrieved by interrogation and traced so that the programmer can determine if the desired response is being achieved.
The debugger can read and write the executable code space of a processor to be debugged. At the location for a break point to be set, an original instruction is removed and saved. A break instruction, for example, a special operational code (opcode) or a non-operation instruction (no-op), is placed at the original instruction location to affect a break in operation. Code execution is then started at a desired location. When execution reaches the newly set break point position, the processor will stop. In order for any execution to continue, through either continued running or single stepping, the original instruction is retrieved from storage and placed in the original location. Execution can proceed and the original intended program behavior results.
Information relating to attempts to improve the art in this area can be found in existing art. For example, U.S. Pat. No. 5,740,413, to Alpert et al., describes a method and apparatus for providing address break points, branch break points, and single stepping. Further, U.S. Patent Application Publication No. 2002/0170030, to Halcomb et al., describes downloading programs into a programmable logic device (PLD) for mimicking processor operations in an emulation operation.
However, these references suffer a disadvantage in one or more areas: none allow original code to override special break instructions that have been written into program storage to represent break points when restarting or single stepping code, none allow break point manipulation at hardware speeds, none handles a step out function where recursive functions may be incorporated, none manage break points without involving the debugger directly in detailed stepping methods and none handle these aspects from an on-chip debugging situation.
Under the existing art, stepping through programs involves significant amounts of emulator intervention, performing a small number of steps and reading out the status of the processor to determine what to do next. Performing step-over and step-out operations that also correctly handle recursive calls can consume vast amounts of time if no hardware support is available in an on-chip debug module. What is needed is a method that allows execution of the majority of the instructions at full speed while performing step-over and step-out functions. Since these functions can require millions of processor instructions to complete, considerable execution benefit is gained. Furthermore, as an on-chip debug module adds cost to each device it is added to, being able to reuse existing hardware in formation of the on-chip debug module would be a great benefit.
The present invention is directed to an apparatus for rapidly stepping through programming statements while debugging. The apparatus is a debug module for managing execution of software on a target processor during debug. The debug module contains a physical layer configured to connect the debug module to an emulator for the exchange of debug information. The debug module also contains an access control layer, which implements general access to the debug module. The access control layer is configured to receive communication control commands, register identification, and mode control commands from the emulator. The debug module also contains an application layer to manage operation of the target processor. The application layer is configured to receive commands, mode settings, and processor instruction data from the emulator.
The present invention is also directed to a method for stepping over function calls in software executing on a target processor. This method involves setting one or more break points in the software to be executed by updating the program storage as required by the break points set, setting the debug mode to step-over, scanning the program storage from the current program location to find the next sequential symbolic break point, setting the contents of the debug register to any break point address found in the scanning step or to a maximum offset from current program location if no breakpoint address found, setting the program counter to the point of desired execution in the program, starting execution of said program, halting program execution when the program counter equals the contents of the debug register, a break instruction is executed or a specific change in flow is encountered. If no break instruction or symbolic breakpoint is found at the current program counter, the process is repeated from the scanning stage, otherwise the process is completed by reading and correcting the program counter.
The present invention is also directed to a method for stepping out of function calls in software executing on a target processor. This method involves setting one or more break points in the software to be executed, updating the program storage as required by the break points set, setting the debug mode to step-out, setting the call level counter register to zero, setting the program counter to the first point of desired execution in the program, starting execution of the program, halting program execution when the call level counter becomes less than zero, and reading and correcting the program counter.
These and other features, aspects, and advantages of the present invention will become better understood with reference to the following description and appended claims.
With respect to
The debug host platform 105, in the form of, for example, a personal computer, contains a general programming environment comprised of a software development tool suite 110 and a debug software application 115. An executable image file 135 is accessible by the software development tool suite 110 and the debug software 115. The debug software uses information from the image file 135 to build a symbol table 117. The symbol table contains, amongst other things, the addresses of the high-level instructions in the program to be debugged. These addresses are used during debugging as symbolic break points. The debug host platform 105, through internal connections and devices (not shown), couples the software development tool suite 110 and debug software 115 to an interface (I/F) 160, which couples to the emulator 125 through a connection bus 130A. The emulator may contain an event memory 127 containing a copy of all or part of the symbol table 117. The connection between the debug host platform 105 interface 160 and the emulator 125 could be, for example, an RS232 bus, a Universal Serial Bus (USB), or fiber optic connection.
The integrated circuit chip 150 contains a debug module 140, a target processor 120, and a program storage 170. The emulator 125 connects to the integrated circuit chip 150 by a bus connection 130B through the debug module 140. The debug module 140 connects to the target processor 120 directly and through a multiplexer 155. The target processor 120 also connects to the program storage 170.
Within the debug host platform 105, the debug software 115 provides a user with a graphical interface composed of windows (not shown), each window representing a different view of a debugging process. The debug software 115 is integrated with other applications, such as the software development tool suite 110, to form a general programming environment, which a user can use to determine proper program operation of code executing on the target processor 120.
The target processor 120 may generally contain a program counter 250 (
The access control state machine 225 is connected to a flow control state machine 245 in an application layer 265. The access control state machine 225 is used for managing an access command state (not shown) and coordinating command state information with the flow control state machine 245. A flow command register 240 and a mode register 235 are connected to the flow control state machine 245 so that their contents can direct the flow control state machine 245. The flow control state machine 245 is further connected to an interface (not shown) on the target processor 120 for control of execution to be carried out.
The application layer 265 contains a signature register 257, which is used by the debug software 115 to identify the device being debugged. An override instruction register 255 is located in the application layer 265 so that the emulator 125 can send intervening instructions to the target processor 120 without having to update the program storage 170 each time a program restart or single step from a location containing a Break instruction 310 is desired. During debug operations, a debug register 260, will contain either an address of a break point or a count of functions called. The count of called functions will be incremented and decremented in the debug register 260 as function calls are entered or returned from respectively, during debug. The signature register 257, the override instruction register 255, and the debug register 260 are each connected to the debug module data bus 210. A core 270 within the target processor 120 is connected to the debug module 140 by the debug module data bus 210. A program counter 250 inside the core 270 is accessed by the debug module 140 to observe and control the program location being executed by the target processor 120.
In
The instruction address bus 370 connects the program counter 250 of the target processor 120 to the program storage 170, and a comparator 330. An output of the debug register 260 and the instruction address bus 370 are inputs to the comparator 330, whose output is connected to the flow control state machine 245. Program counter 250 addresses are put on the instruction address bus 370 in the course of program execution and can be compared to an address in the debug register 260. When an address on the instruction address bus 370 matches the address stored in the debug register 260, a signal is sent to the flow control state machine 245 to halt target processor 120 execution by forcing a hardwired break instruction 310 to the instruction register 315 if enabled in the present mode of operation as given by the mode register 235.
An output of the override instruction register 255 is connected to a second multiplexer 320, which is controlled by the flow control state machine 245. The second multiplexer 320 is also fed by a general purpose program storage, for example, a ROM 345 and a hardwired break instruction 310. The general purpose program storage could also be configured with a FLASH device, an EPROM or an SRAM. The content of the override instruction register 255 depends on the mode of operation. The override instruction register can provide an alternate instruction source or select a program type within the ROM 345. Under control of the flow control state machine 245 any of these input quantities to the second multiplexer 320 can be fed to the first multiplexer 155 and from there to the instruction register 315 of the target processor 120 when an alternate instruction control signal 350 is selected from the flow control state machine 245.
The various register elements and control state machine combinations, are well known to one skilled in the art, to be capable of implementation by any number of circuit combinations of, for example, flip-flops, flip-flops with clocked latches, microsequencer with programmable control memory and state registers, or latching storage elements with combinatorial circuitry.
The stopped state 420 is also reached from the running state 401 when a break instruction 310 is executed during program code execution. From the stopped state 420 program execution may be resumed by a go command 435 or go with override 440 command, either of which will create a transition to the running state 401. The running state 401 is also reached when the external event reset and no reset flag 405 is set.
The following table denotes an exemplary set of command byte codes that are relevant to the present invention. Note that some byte codes not set forth may also be reserved for future use.
In another exemplary embodiment of the present invention, a debug software program 115 and software development tool suite 110 are configured as shown in
Nominally, changes in the sequential flow of instructions can, for example, be categorized in an exemplary embodiment as follows:
Instruction Category
When the debug mode is not either step over or step out, the first 3 categories are controlled by a flow control setting of break on change of flow and the last category is controlled by a break on interrupt flow control setting (refer to Command Byte Code Table, Flow Control Settings). The step over mode takes special control of these categories. In step over mode categories 1 and 2 are enabled but 3 and 4 are used to manage the full speed execution of code over function calls and hardware interrupts.
Continuing execution in the step out mode allows for nested levels of function calls to be executed continuously at full processor speed and without intervention until returning to the calling location. This is facilitated by the debug register use changing from storing a break point to storing an up-down count during call level counting in nested function calls.
Change of flow break points are disabled in the step out mode allowing for function calls and hardware interrupt handler code to be executed at full speed until the debug register 260 contents becoming less than zero signals a completion of execution and return back to the calling point in the code. The management of calling program levels is done by incrementing the call level counter value in the debug register 260 with each function called or interrupt service routine invoked and decrementing it with each return from a called function or an invoked interrupt service routine. When the count becomes less than zero, execution has returned to the calling location and recursive function calls have been properly handled. The value in the debug register 260 being less than zero will cause the flow control state machine 245 to create a break in execution.
Although the present invention has been described in terms of exemplary embodiments, one skilled in the art will recognize that additional embodiments could readily be conceived which will still be within a scope of the present invention. For example, particular process flow diagrams, debug system diagrams, and integrated processor systems are presented as exemplary embodiments of approaches for implementing these stepping methods. However, a skilled artisan could readily rearrange certain steps within the process flow diagrams, implement alternative debug systems, employ different emulator systems, use alternate integrated development environments (IDEs) for software investigation, incorporate different bus structures coupling storage elements in a communication hierarchy, and achieve the same result of determining break points and running executable image files 135 at full speed. Therefore, the scope of the present invention shall only be limited by the appended claims.