Patent Application
20070168736
This disclosure relates generally to software, and in particular but not exclusively, relates to logically grouping breakpoints for software debugging.
To test, debug, and/or develop a software program for execution on a processing system, it is often desired to be able to stop the processor's execution of instructions at a specific place in the software program using a breakpoint. Typically, a breakpoint is inserted at a location that is of some significance to the program and/or machine executing the program. The program is then executed and a debugger tool used to examine the program's behavior. When the breakpoint is reached during the runtime, control is returned to the user, so that the user can single-step forward execution of the program and view the current state of software variable and hardware registers to determine what occurred during execution.
One conventional approach of accomplishing this function involves providing a register and a multi-bit comparator. The comparator compares a multi-bit address value stored in the register with a multi-bit address value present on the address bus of the processor. The output of the comparator is a halt signal that is supplied to the processor. To set a breakpoint to stop the processor at a particular address, the user writes the address into the register. Execution of the instructions of the program is then commenced. When the processor reaches the instruction that is stored at the address value in the register, the comparator determines that the address value in the register is the same value that is on the address bus of the processor. The comparator therefore outputs the halt signal and the halt signal in turn stops the processor. An external debugging tool is commonly provided whereby the user can determine the contents of the halted processor's internal registers. This approach that uses a register and comparator is sometimes called a hardware breakpoint.
Another conventional approach to providing a breakpoint is called a software breakpoint. One of the operation codes (opcodes) of the processor is a breakpoint instruction opcode. This instruction opcode may, in some systems, be an illegal instruction that is not used in the instruction set. In other systems it is an opcode of a legitimate instruction of the instruction set that is executed by the processor. When the processor fetches this particular opcode from program memory and decodes it, the processor detects the breakpoint instruction and takes a particular action. The particular action may, for example, be to halt. In another example, the processor may jump to a particular location. In another example, the processor may signal that the processor has reached a breakpoint instruction.
To place a software breakpoint into a program that is being debugged, the user typically overwrites a particular instruction of the program code in memory with the breakpoint instruction. The processor then commences execution of the program code. When the processor fetches and decodes the breakpoint instruction, the processor halts and performs the operation to be performed by the breakpoint instruction. Again, as in the hardware breakpoint example, a debugging tool is typically used to determine the contents of the processor's internal registers or to otherwise determine the state of the system.
Non-limiting and non-exhaustive embodiments of the invention are described with reference to the following figures, wherein like reference numerals refer to like parts throughout the various views unless otherwise specified.
Embodiments of a system and method for logically grouping breakpoints are described herein. In the following description numerous specific details are set forth to provide a thorough understanding of the embodiments. One skilled in the relevant art will recognize, however, that the techniques described herein can be practiced without one or more of the specific details, or with other methods, components, materials, etc. In other instances, well-known structures, materials, or operations are not shown or described in detail to avoid obscuring certain aspects.
Reference throughout this specification to “one embodiment” or “an embodiment” means that a particular feature, structure, or characteristic described in connection with the embodiment is included in at least one embodiment of the present invention. Thus, the appearances of the phrases “in one embodiment” or “in an embodiment” in various places throughout this specification are not necessarily all referring to the same embodiment. Furthermore, the particular features, structures, or characteristics may be combined in any suitable manner in one or more embodiments.
Each breakpoint of the list of breakpoints 115 represents a pause command inserted at a selected location in a program under test to temporarily halt the program for testing and debugging. Lines in the source code of a program may be marked for breakpoints. Breakpoint instructions are then inserted into the corresponding locations of the executable code (e.g., assembly code or machine code). When the breakpoint instructions are executed, the program under test stops, allowing the programmer to examine the status of the program (registers, variables, etc.). After inspection, the programmer can step through the program one line at a time, cause the program to continue running either to the end or to the next breakpoint, whichever comes first, or stop debugging altogether in order to make code changes. Breakpoints are typically inserted just before or after critical decision points in a program and other informative locations to facilitate code tracing during development, testing, or debugging.
Breakpoint group manager 105 manages the list of breakpoints 115 and the list of breakpoint groups 120 to implement a variety of breakpoint functions. A user of system 100 may desire to group sets of breakpoints 115 for a variety of reasons based on a variety of logical relations. For example, breakpoints 115 may be grouped to test for a specified condition or circumstance. Breakpoints 115 may be grouped to test a particular program module, procedure, object, or entity of a program. Breakpoints 115 may be grouped to test for a specified use-case scenario. Breakpoint group manager 105 enables the user to customize their debugging environment for efficiency when performing iterative testing or debugging.
Breakpoint groups 120 may be created and given a descriptive name. Subsequently, breakpoints 115 may be added or assigned to breakpoint groups 120 from the list of breakpoints 115. Logical relations established by breakpoint groups 120 can then be saved into a breakpoint group file to be reused as often as desired.
Once a breakpoint group 120 has been created and one or more breakpoints 115 added to the new breakpoint group 120, the breakpoint group 120 can have an enabled or disabled status. An enabled status means that all breakpoints 115 assigned to the particular breakpoint group 120 are enabled and will halt execution of the program under test when executed. A disable status means that all breakpoints 115 assigned to the particular break point group 120 are disabled and will not halt execution. In short, breakpoint groups 120 provide a convenient mechanism to associate groups of breakpoints 115 and collectively enable or disable the grouped breakpoints.
Each breakpoint group 120 includes data members that describe the unique properties of the particular breakpoint group 120. For example, the data members may include the group name, the group enable state, an internal group identifier, and a breakpoint list identifying each breakpoint 115 added to the particular breakpoint group 120. In one embodiment, breakpoint groups 120 are implemented as objects instantiated from a group class type in the C++ programming language. When a new breakpoint group 120 is created, the group class type instantiates a new object instance. The newly created breakpoint group 120 is an empty container object ready to be filled with breakpoint handles referencing breakpoints 115. Once multiple breakpoint handles are added to the container object, the corresponding breakpoints 115 are logically grouped and can be collectively enabled or disabled via the assertion of a single command.
The functionality provided by breakpoint group manager 105 is visually accessible to a user of system 100 via GUI 110. This visual accessibility may be implemented using a combination of command line prompts, menus (e.g., pull down menus, popup menus, etc.), viewing panes, windows, buttons, check boxes, and the like. Examples of various visual interfaces generated by GUI 110 for accessing the functionality provided by breakpoint group manager 105 are illustrated in
As mentioned, breakpoint group manager 105 manages breakpoints 110 and breakpoint groups 120. For example, breakpoint group manager 105 may be accessed via GUI 110 to create one or more breakpoint groups 120, to name and rename breakpoint groups 120, to add one or more breakpoints 115 to a particular breakpoint group 120, to delete one or more breakpoints 115 from a particular breakpoint group 120, to delete one or more breakpoint groups 120, to enable or disable one or more breakpoint groups 120, to enable or disable all breakpoint groups 120, and to save breakpoints 115 and breakpoint groups 120 to a project file for later recall.
Although
By clicking the “Choose breakpoints” button while highlighting one of breakpoint groups 201, a GUI window 300 is displayed.
In a process block 505, the user creates or modifies a program under test. The program under test could include any type of program developed using a variety of software languages (e.g., C, C++, Visual Basic, Java, etc.). In a process block 510, the user creates one or more breakpoints. These created breakpoints are added to the list of breakpoints 115. In a process block 515, the user creates one or more breakpoint groups 120 using GUI 110 to interface with breakpoint group manager 105. In a process block 520, the user can then logically associate groups of breakpoints 115 by adding breakpoints 115 to breakpoint groups 120.
Once a breakpoint group 120 has been created and populated with at least one breakpoint 115, the user can perform a number of functions efficiently via GUI 110 (process block 525). For example, the user can name or rename breakpoint groups 120, create a new breakpoint group 120, delete an existing breakpoint group 120, enable selected breakpoint groups 120, disable selected breakpoint groups 120, add or remove breakpoints 115 from breakpoint groups 120, and save breakpoints 115 and breakpoint groups 120 to a project file for later use. GUI 110 and breakpoint group manager 105 enable a user to collectively enable or disable all breakpoints 115 of a single breakpoint group 120 by asserting a single command (e.g., clicking the checkboxes in viewing pane 205 (see
Once the user has enabled the desired breakpoint groups 120, the program under test can be executed using a debugger tool (process block 530). When the program execution reaches one of the enabled breakpoints 115, execution of the program under test is temporarily halted, allowing the user to view internal variables or advance execution one instruction at a time (process block 535). If the program under test reaches the end of execution without error (decision block 540), then debugging is complete in a process block 545. However, if further testing is required, then the user can return to several possible stages to continue development, testing, or debugging.
The elements of processing system 600 are interconnected as follows. Processor(s) 605 is communicatively coupled to system memory 610, NV memory 615, DSU 620, and communication link 625, via chipset 630 to send and to receive instructions or data thereto/therefrom. In one embodiment, NV memory 615 is a flash memory device. In other embodiments, NV memory 615 includes any one of read only memory (“ROM”), programmable ROM, erasable programmable ROM, electrically erasable programmable ROM, or the like. In one embodiment, system memory 610 includes random access memory (“RAM”), such as dynamic RAM (“DRAM”), synchronous DRAM, (“SDRAM”), double data rate SDRAM (“DDR SDRAM”) static RAM (“SRAM”), and the like. DSU 620 represents any storage device for software data, applications, and/or operating systems, but will most typically be a nonvolatile storage device. DSU 620 may optionally include one or more of an integrated drive electronic (“IDE”) hard disk, an enhanced IDE (“EIDE”) hard disk, a redundant array of independent disks (“RAID”), a small computer system interface (“SCSI”) hard disk, and the like. Although DSU 620 is illustrated as internal to processing system 600, DSU 620 may be externally coupled to processing system 600. Communication link 625 may couple processing system 600 to a network such that processing system 600 may communicate over the network with one or more other computers. Communication link 625 may include a modem, an Ethernet card, a Gigabit Ethernet card, Universal Serial Bus (“USB”) port, a wireless network interface card, a fiber optic interface, or the like.
It should be appreciated that various other elements of processing system 600 have been excluded from
The techniques described above in connection with process 500 may constitute machine-executable instructions embodied within a machine (e.g., computer) accessible medium, which when executed by a machine will cause the machine to perform the operations described herein. Additionally, the processes may be embodied within hardware, such as an application specific integrated circuit (“ASIC”) or the like. A machine-accessible medium includes any mechanism that provides (i.e., stores and/or transmits) information in a form accessible by a machine (e.g., a computer, network device, personal digital assistant, manufacturing tool, any device with a set of one or more processors, etc.). For example, a machine-accessible medium includes recordable/non-recordable media (e.g., read only memory (ROM); random access memory (RAM); magnetic disk storage media; optical storage media; flash memory devices; etc.), as well as electrical, optical, acoustical or other form of propagated signals (e.g., carrier waves, infrared signals, digital signals, etc.); etc.
The above description of illustrated embodiments of the invention, including what is described in the Abstract, is not intended to be exhaustive or to limit the invention to the precise forms disclosed. While specific embodiments of, and examples for, the invention are described herein for illustrative purposes, various modifications are possible within the scope of the invention, as those skilled in the relevant art will recognize.
These modifications can be made to the invention in light of the above detailed description. The terms used in the following claims should not be construed to limit the invention to the specific embodiments disclosed in the specification. Rather, the scope of the invention is to be determined entirely by the following claims, which are to be construed in accordance with established doctrines of claim interpretation.
