Patent Application
20050289396
Modem software debugging tools offer a wide range of features, but most have some sort of breakpointing mechanism to control program execution during a debug session. A breakpoint is used to halt program execution when a certain point in the program is reached. For example, a user can set a breakpoint at a specific line of code at which program execution is to be halted. Some software debugging tools even allow a user to set a breakpoint with a condition. Such a breakpoint is called a conditional breakpoint. Conditional breakpoints only stop or pause program execution if a specified condition is true. The condition is an expression that is evaluated when the breakpoint is encountered during program execution. The expression accesses program variables. If, while the program is executing, the expression evaluates to true, the program pauses, thus allowing the user to inspect the program variables.
Like reference numerals will be used to represent like elements.
Still referring to
In the illustrated embodiment, the user interface 12 includes a graphical user interface (GUI) 26 as well as a command line interface (CLI) 28. A user can use one or both of these interfaces to interact with the simulator 14 in setting a conditional breakpoint on an instruction of the user program.
The conditional breakpoint mechanism allows a user to set a conditional breakpoint at a desired location in the user program, for example, on a particular instruction (“breakpoint instruction”). The conditional breakpoint has an associated function that is executed when the breakpoint instruction is reached during simulation. The breakpoint function results determine whether the program execution during simulation will be paused or will continue uninterrupted.
The breakpoint functions 16 may be implemented in any form that is understood by the simulator 14, e.g., in an interpreted (or scripting) language such as interpreted C, or a high-level system programming language such as C++. The breakpoint function can be made available to the simulator 14 in different ways, for example, it may be provided in a script created using the GUI 26 or CLI 28, or as a compiled software routine in a dynamic linked library (DLL). Scripts may be stored in script files (as script files 18) and executed by the user during simulation or as part of the simulation startup routine to load the functions into the simulator. Typically, script files are used to configure and control the simulation, as well as to access and manipulate simulation states. They may include a mixture of built-in simulator commands and interpreted source code (such as interpreted C). In addition, or alternatively, the breakpoint function may be defined interactively at the CLI command line or under GUI controls using a breakpoint editor, and then stored locally at the simulator (as shown in
Foreign models can be used to integrate models of external hardware that may be connected to the target processor. Thus, the foreign model provides a mechanism by which the processor software model (of the simulator 14) can be extended to include additional software models of hardware that interfaces with the processor. One way to integrate a foreign model with the simulator is by creating a foreign model DLL. In the described embodiment, breakpoint functions may be defined in the foreign model DLL. The ability to define a breakpoint function in a foreign model DLL is particularly useful for more complex breakpoint functions, as the compiled code of the foreign model executes much faster than does its scripted language equivalent.
The foreign model DLL is activated by executing a ‘foreign_model’ command at the CLI command prompt or using appropriate simulation menu options of the GUI to cause the simulator to execute the command. When the simulator executes the foreign model command, it loads and initializes the foreign model DLL as well as obtains pointers to the foreign model functions to bind the foreign model DLL to the simulator. The foreign model maybe written in a high-level language like C++ that has access to chip simulator states, can receive callbacks from the simulator upon certain events (e.g., reset or simulation time change), and can register a breakpoint function for use by the command line or script. Thus, the breakpoint function 16 is a function available for calling on the simulator command line and by the interpreted source code of a script. The breakpoint function can be defined directly in a script file or can be defined in a foreign model and registered for use by the command line or script.
In the illustrated embodiment, the simulator 14 contains a built-in interpreter 30 to execute native simulator commands and other commands written in an interpreted (or scripting) language, such as interpreted C and Tcl. The interpreter 30 thus provides the simulator 14 with scripting capability so that script files can be used to run a sequence of native simulator and interpreted commands (e.g., C interpreted commands). The simulator 14 also maintains in a local table 32 breakpoint state (“breakpoint watch”) for each breakpoint that is established.
Although not depicted in
Referring now to
At some point after the breakpoint has been set on an instruction in the user program, the simulator 14 will start or resume code execution during a simulation session (block 54). As the code of the user program executes, line by line, the simulator 14 compares values corresponding to the executing instructions (e.g., program counter values, code line numbers, addresses or any other values that may be used to identify the instructions) to the breakpoint watch information to determine if the breakpoint instruction has been reached (block 56). If it is determined (at block 56) that the breakpoint instruction has been reached, the simulator 14 calls the breakpoint function associated with the breakpoint to execute (block 58). When a value is returned by the breakpoint function (block 60), the simulator 14 determines if that value indicates that a break should occur (block 62). If the returned value is true (“1”), the simulator 14 causes a break in the program execution (block 64). If the returned value is false (“0”), the simulator 14 allows the program execution to continue (returns to block 54) without pausing or stopping.
The operational flow of
In one embodiment, the conditional breakpointing mechanism may be used in a multi-processor and multi-thread simulation. For example, and referring to
In network processing applications, where the processor 70 is used as a network processor, the MEs 72 may be used as a high-speed data path, and the general purpose processor 76 may be used as a control plane processor that supports higher layer network processing tasks that cannot be handled by the MEs.
In the illustrative example, the MEs 72 each operate with shared resources including, for example, an external memory system interface 78, an external bus interface 80, an I/O interface 82 and Control and Status Registers (CSRs) 84, as shown. The I/O interface 82 is responsible for controlling and interfacing the processor 70 to various external I/O devices. The external memory system interface 78 is used to access an external memory system. For networking applications, the I/O devices can be any network devices capable of transmitting and/or receiving network traffic data, such as framing/MAC devices, or devices for connecting to a switch fabric. Other devices, such as a host computer and/or bus peripherals (not shown), which may be coupled to an external bus controlled by the external bus interface 80 can also serviced by the processor 70. Each of the functional units of the processor 70 is coupled to an internal bus structure or interconnect 86.
In general, as a network processor, the processor 70 can interface to any type of communication device or interface that receives/sends data. The processor 70 functioning as a network processor could receive units of information from a network device and process those units in a parallel manner. The unit of information could include an entire network packet (e.g., Ethernet packet) or a portion of such a packet, e.g., a cell such as a Common Switch Interface (or “CSIX”) cell or ATM cell, or packet segment.
Referring to
The microcontroller 94 includes instruction decoder and program counter (PC) units for each of the supported threads. The context arbiter/event logic 96 can receive messages from any of the shared resources, e.g., the external memory, or general purpose processor 76, and so forth. These messages provide information on whether a requested task has been completed. The ME 72 also includes an execution datapath 98 and a general purpose register (GPR) file unit 100 that is coupled to the control unit 90. The GPRs are read and written exclusively under program control. The GPRs, when used as a source in an instruction, supply operands to the datapath 98. When used as a destination in an instruction, they are written with the result of the datapath 98. The instruction specifies the register number of the specific GPRs that are selected for a source or destination. Opcode bits in the instruction provided by the control unit 90 select which datapath element is to perform the operation defined by the instruction.
The ME 72 further includes write transfer (transfer out) register file 102 and a read transfer (transfer in) register file 104. The write transfer registers of the write transfer register file 102 store data to be written to a resource external to the microengine. The read transfer register file 104 is used for storing return data from a resource external to the ME. The transfer register files 102, 104 are connected to the datapath 98, as well as the control unit 90.
Also included in the ME 72 is a local memory 108. The local memory 108, which is addressed by LM address registers 110, supplies operands to the datapath 98, and receives results from the datapath 98 as a destination.
The ME 72 also includes local control and status registers (CSRs) 112, coupled to the transfer registers, for storing local inter-thread and global event signaling information, as well as other control and status information. Other register types of the ME 72 include next neighbor (NN) registers 114, coupled to the control unit 90 and the execution datapath 98, for storing information received from a previous neighbor ME (“upstream ME”) in pipeline processing over a next neighbor input signal 116a, or from the same ME, as controlled by information in the local CSRs 112. A next neighbor output signal 116b to a next neighbor ME (“downstream ME”) in a processing pipeline can be provided under the control of the local CSRs 112. Thus, a thread on any ME can signal a thread on the next ME via the next neighbor signaling.
The typedef designation for the imported function passes similar information. An example typedef designation for an imported function would be: ‘int func_name(char*chip_name, int me_num, int ctx_num, int PC);’.
When the breakpoint command is received, the simulator 14 verifies that the specified breakpoint function, if any, has been previously defined and registered, and conforms to the calling standard. If the breakpoint function has not yet been defined and registered, or does not conform to the calling standard, an error is reported and the breakpoint is not established. When it is time for the simulator 14 to call the breakpoint function, and the breakpoint function is not currently defined for some reason or is defined but does not conform to the calling standard, then a simulation error is reported and program execution pauses as if the breakpoint function had returned a non-zero value. In one embodiment, the simulator 14 automatically removes breakpoints when the corresponding breakpoint function is removed.
Conditional breakpoints can be applied to all contexts or only selected contexts. If the conditional breakpoint is applied to all contexts for a given instruction, the simulator halts program execution when any context in the ME reaches that instruction. If the conditional breakpoint is applied to only one or some of the contexts for a given instruction, then the simulator halts program execution when any context (in the ME) the user has assigned to the breakpoint reaches that instruction.
As described earlier, and referring back to
The use of the GUI to set a conditional breakpoint will now be described with reference to
In response to the user selecting ‘Breakpoint Properties’ 148, the GUI presents the user with a breakpoint properties editor. In the illustrated embodiment, and referring now to
Still referring to
Thus, according to one GUI-based technique, the user types the body text of the breakpoint function into the text box 176 provided by the Breakpoint Properties dialog. When the Breakpoint Properties dialog is closed (by clicking an ‘OK’ button 180) to accept the changes, the GUI 26 provides the breakpoint function definition text directly to the simulator 14 in order to define and register the breakpoint function. If the breakpoint function needs to change, the user can open the Breakpoint Properties dialog box and modify the body text. When the Breakpoint Properties dialog box is closed, the GUI 26 redefines the previous breakpoint function definition in the simulator 14. When the breakpoint function is either created or edited using the Breakpoint Properties dialog, the change takes effect when the dialog is applied (e.g., when the user clicks the OK button 180). If the breakpoint function previously existed, it is automatically removed and then redefined. The change therefore takes effect immediately, without the user exiting and restarting the simulation.
According to another GUI-based technique, the user types the name of a breakpoint function name into field 172 (provided by the Breakpoint Properties dialog box) to use a breakpoint function contained in a script or foreign model. In the case of a script, the user is responsible for defining the breakpoint function manually in a script file or by typing the function text directly on the command line of the command line interface (CLI). If the breakpoint function body needs to change, the user is responsible for removing the old definition using a simulator ‘remove’ command before entering in the new definition. The user simply edits the script file whenever the breakpoint function definition needs to change. In the case of a foreign model, the user must have previously defined the breakpoint function in a foreign model specified through the user interface and loaded at simulation startup.
Once in the dialog box 150, the user can select or clear ‘Enabled’ box 156 to enable or disable the breakpoint, select contexts and select (or change) the functions the user wishes to associate with the breakpoint. Other properties may be specified as well. The user can also remove a breakpoint from within the dialog box by clicking on a remove button 178. With both of above GUI-based techniques, the GUI 26 will issue the breakpoint command to the simulator 14 to establish the conditional breakpoint (if not already established).
If the dialog box is not used to set the breakpoint, but instead the CLI is used to set the breakpoint, the user can still place the breakpoint function definition in a script file that is executed automatically at simulation startup or use a breakpoint function defined in a foreign model. As discussed earlier, the user can type the breakpoint command (for example, according to the format shown in
When a breakpoint is set on a microcode instruction, a breakpoint icon may be displayed in the left-hand margin of the corresponding line in the Thread Window 142. The breakpoint icon's appearance may be designed to convey the properties of the breakpoint. For example, the Thread Window 142 may mark a conditional breakpoint that uses a breakpoint function with a different icon or set of icons than those used to indicate unconditional breakpoints.
Although not illustrated, it will be appreciated that any of the breakpoint “options” (e.g., Enable/Disable Breakpoint, Insert/Remove Breakpoint and Breakpoint Properties) may be available through appropriate GUI Debug toolbar and menu selections as well. On the Debug menu, for example, the user may click ‘Breakpoint’ followed by ‘Insert/Remove’ (or the equivalent function key or button on the Debug toolbar). The Breakpoint Properties Dialog Box can also be reached from the Debug menu (by clicking ‘Breakpoint’ followed by ‘Properties’) as well.
The conditional breakpointing mechanism of the described embodiment allows the breakpoint to be established in two parts, breakpoint function definition and breakpoint command issuance, thus providing for a breakpoint command that is de-coupled from the breakpoint function definition. Because of the de-coupled nature of the breakpoint command and function, the user has the flexibility to move a breakpoint function to different PC, thread, ME or chip just by issuing a ‘remove breakpoint’ command (e.g., by clicking the remove button 178 in the Breakpoint Properties dialog box 150, or using the menu option ‘Insert/Remove Breakpoint’ 145) and then issuing a new breakpoint command (as described above) that provides the new values for the breakpoint function arguments.
Breakpoint functions may be defined to do any number of different tasks, for example, to test and set simulation states, create and manipulate variables, call other functions, and execute built-in console commands. In a simple example, a breakpoint function could be defined to execute a console command, such as print statement (to print to the CLI), and return a zero so that a break does not occur. This would be useful to report some event to the user, for example, that a particular processing stage has been entered by an ME. In another example, a breakpoint function could be defined to perform some type of diagnostic test, such as inspecting a variable for an expected value, to detect an error condition and return a ‘1’ only if the error condition is detected. The breakpoint function could also log the error. In a more complex networking application example, the breakpoint function could be used to diagnose a rate problem. A first breakpoint could be set with a function to record a cycle time without breaking and a second breakpoint could be set with a function to calculate a time difference (using the earlier recorded time value and a current time value) to determine if the rate at which processing is occurring exceeds a desired or required rate budget, breaking only if the condition is satisfied. Example interpreted C code to implement a breakpoint function for yet another network application example is shown below:
In the above example, the breakpoint function accesses an IP destination address variable (“da”), tests whether its value is within a specified range of values, and breaks only if the condition is satisfied.
Referring to
Suitable processors include, by way of example, both general and special purpose microprocessors. Generally, the processor 202 will receive instructions and data from a read-only memory (ROM) 204 and/or a random access memory (RAM) 206 through a CPU bus 208. A computer can generally also receive programs and data from a storage medium such as an internal disk 210 operating through a mass storage interface 212 or a removable disk 214 operating through an I/O interface 216. The flow of data over an I/O bus 218 to and from devices 210, 214, (as well as input device 216, and output device 218) and the processor 202 and memory 206, 204 is controlled by an I/O controller 220. User input is obtained through the input device 216, which can be a keyboard (as shown), mouse, stylus, microphone, trackball, touch-sensitive screen, or other input device. These elements will be found in a conventional desktop computer as well as other computers suitable for executing computer programs implementing the methods described here, which may be used in conjunction with output device 218, which can be any display device (as shown), or other raster output device capable of producing color or gray scale pixels on paper, film, display screen, or other output medium.
Storage devices suitable for tangibly embodying computer program instructions include all forms of non-volatile memory, including by way of example semiconductor memory devices, such as EPROM, EEPROM, and flash memory devices; magnetic disks s u c h as internal hard disks 210 and removable disks 214; magneto-optical disks; and CD-ROM disks. Any of the foregoing may be supplemented by, or incorporated in, specially-designed ASICs (application-specific integrated circuits).
Typically, the debugger 10 and other related processes reside on the internal disk 210. These processes are executed by the processor 202 in response to a user request to the computer system's operating system after being loaded into memory. Any files or records produced by these processes may be retrieved from a mass storage device such as the internal disk 210 or other local memory, such as RAM 206 or ROM 204.
The system 200 illustrates a system configuration in which the debugger 10 is installed on a single stand-alone system. In another configuration, the debugger 10 may be installed on a networked computer system for local user access. In yet another configuration, the software or portions of the software provided or used by the debugger 10 may be installed on a file server to which the system 200 is connected by a network, and the user of the system accesses the debugger software over the network. The foreign model (shown as a part of the debugger 10) may run on the same system as the simulator, or may run on a different system. For example, the simulator 14 may communicate over a network with a foreign model running on a remote system. Also, the debugger may be configured to operate in a hardware debugging mode in additional to simulation mode, and thus debugger/system 200 could be coupled to and communicating with (over a network or serial port) a subsystem containing the actual target processor.
Other embodiments are within the scope of the following claims.
