Navigating breakpoints in a program in a debugging mode

Provided is a method, system, and program for navigating breakpoints in a program in a debugging mode. A user interface is rendered to display at least one program corresponding to at least one object file being executed in a debugging mode. A list is maintained of breakpoints in the at least one program. Code is rendered from one program including a selected first breakpoint. User input is received to access a second breakpoint and a selection is made from the list of the second breakpoint in one of the program. Code is rendered from one program including the selected second breakpoint

BACKGROUND

Systems in a network environment communicate information in packets that encapsulate the information according to network communication protocols. Packets transmitted from one node to another node may be transmitted through one or more intervening routers that route the packets throughout the network or between networks. The router typically includes one or more network processors to process the packets. The network processor stores packets in a memory device, such as a Static Dynamic Random Access Memory (SDRAM) and stores packet management information, such as packet queues in a Static Random Access Memory (SRAM). The network processor may include a plurality of packet engines, also known as microengines. Each packet engine executes code, known as microcode, to perform a particular packet processing operations.

A developer writing microcode for the packet engines may use an integrated development tool to debug the code. The developer may create one or more source files that when compiled or assembled produce one or more list files. The developer may then assign each list file to a different packet engine. A linker converts the list files to executable microcode that is loaded by the microcode loader into a packet engine. The developer may then use a debugger function within an integrated development environment (IDE) tool to observe the list file code corresponding to the microcode being executed by the packet engines.

The user may set breakpoints in the source file or list file to debug the program. A breakpoint causes a halt in the execution of the code. A breakpoint set in the source or list file causes the execution to stop when the breakpoint is executed to allow the developer to observe how execution has proceeded up to that breakpoint. Breakpoints separate the program into sections to allow the developer to focus on those sections having problems, whereas sections between breakpoints that do not have problems can be bypassed. An example of an IDE tool used to develop code for network processor packet engines is described in the publication “Intel® IXP2400/IXP2800 Network Processor Development Tools User's Guide”, order no. 278733-007 (Copyright Intel Corporation, July 2003)

DETAILED DESCRIPTION

A network processor comprises any device that executes programs to handle packets in a data network, such as processors on router line cards, network access equipment and packet forwarding devices.FIG. 1illustrates one example of a network processor2including packet engines4a,4b. . .4ncomprising high speed processors specialized for packet processing. The packet engines4a,4b. . .4nmay comprise any programmable engine or processor for processing packets, such as a microengine, etc. The packet engines4a,4b. . .4nmay execute microcode6a,6b. . .6n, such as microblocks, to process packets, where the microcode6a,6b. . .6ncomprises fast-path packet processing logic executed by the packet engines4a,4b. . .4n. The packet engines4a,4b. . .4nmay instantiate multiple threads to execute different parts of the microcode6a,6b. . .6n. The network processor2may include an on-board memory device8to store packets and other packet processing related information that is accessible to the packet engines4a,4b. . .4n.

FIG. 2illustrates a developer computer system20that a programmer or developer creating microcode4a,4b. . .4nmay use, including a software development tool22to use to create, test and debug microcode and a user interface view24generated by the development tool22to enable the user to interface with the debugger program. A network processor simulator26may execute code being developed and tested using the development tool22and simulate the operation of one or more packet engines4a,4b. . .4n, and the threads executing in each packet engine, on one or more network processors26executing the microcode in development. The developer may configure the network processor simulator26to set the parameters of the simulation environment, such as the clock frequencies of the packet engines, settings for memory devices8used by the network processor6, such as clock frequency and byte size, bus settings, etc. The developer may further configure packet simulation parameters in the simulation environment that the simulated network processor processes using the microcode subject to the debugging operations.

FIG. 3illustrates programs and elements in the development tool22to perform microcode development related operations. Source files30include the source code for the microcode being developed. The source files30may be created in assembly language or Microengine C. The programs to create the source files30may be incorporated into the development tool22. A compiler/assembler32program would translate the source files30into list files34. The compiled or assembled list files34differ from the source code in that symbols may be replaced with actual values, instructions may be reordered for optimization, and the names of local registers are included. The list files34may be provided to a linker36program, which then translates the list files34into executable microcode38object files. In certain embodiments, the user may create build settings40to associate list files34with packet engines4a,4b. . .4n, such that one list file34is associated with one packet engine4a,4b. . .4n, so that the assigned packet engine4a,4b. . .4nexecutes the microcode6a,6b. . .6ngenerated from the list file indicated in the assignment. The microcode6a,6b. . .6ngenerated from the list files34are loaded into the associated packet engines4a,4b. . .4nand executed by threads in the packet engine4a,4b. . .4n. A microcode loader42may load the generated microcode6a,6b. . .6ninto the appropriate packet engine4a,4b. . .4nor simulated packet engine if the network processor simulator26is used. In this way, the build settings40are used to control how list files34and their corresponding microcode are assigned to packet engines4a,4b. . .4n.

FIG. 4illustrates components implemented in the development tool22to perform debugging related operations. The simulator26simulates packet engines4a,4b. . .4nthat launch threads to execute the microcode6a,6b. . .6ngenerated from the list files34. A debugger70is the program that enables a user to perform debugging related operations. The debugger70maintains an association72of list files34to the executable microcode6a,6b. . .6n. This debugger70uses this association72to render in a debugger user interface74the code of the list files34corresponding to the microcode6a,6b. . .6nbeing executed by simulated or real packet engines4a,4b. . .4n. When viewing the list file34code in the debugger user interface74, the developer may set breakpoints in the list file, which are used to stop execution at selected points in the code. Upon setting a breakpoint, the debugger70adds an entry to the global breakpoint list78including information on the breakpoint.

FIG. 5illustrates information maintained in an entry80in the global breakpoint list78including a breakpoint number82; the list file84in which the breakpoint is included; the packet engine86that executes the microcode generated from the list file84; and a line number86on in the list file on which the breakpoint is set.

FIG. 6illustrates a user interface panel100rendered in the debugger user interface74. Breakpoint indicators102a,102breference a breakpoint at a particular line in the code of the list file34. An execution indicator104references a line of the compiled code whose corresponding executable code is currently being executed by a packet engine4a,4b. . .4nin the simulator26. The panel100includes a packet engine, i.e., microengine, drop down menu106to enable the developer to select a packet engine4a,4b. . .4nto cause the debugger70to display the list file code corresponding to the microcode6a,6b. . .6nexecuted by the selected packet engine4a,4b. . .4n, e.g., microengine. A thread drop down menu108enables the display of that portion of the list file34including the list file code corresponding to the microcode being executed on the selected thread in the selected packet engine, i.e., microengine. In certain embodiments, the threads of one packet engine4a,4b. . .4nexecute the same microcode6a,6b. . .6ngenerated from the same list file. The packet engines4a,4b. . .4nmay be ordered, where such ordering is indicated in the hardware, simulator26, or software. A breakpoint navigation menu110enables the following listed breakpoint navigation operations:Next breakpoint in microengine 112: the debugger70selects a next breakpoint in the list file being displayed in the panel100if there is a next breakpoint. If the current selected breakpoint is the last breakpoint in the list file, then the debugger70selects and displays the first breakpoint in the current list file being displayed.Next breakpoint in project 114: the debugger70selects a next breakpoint in the list file being displayed in the panel100if there is a next breakpoint. If the current selected breakpoint is the last breakpoint in the list file, then the debugger70selects the first breakpoint in the list file corresponding to the microcode executed by a next packet engine4a,4b. . .4n, i.e., microengine, according to a packet4a,4b. . .4nordering.Previous breakpoint in project 116: the debugger selects a previous breakpoint in the list file being displayed in the panel100if there is a previous breakpoint. If the current selected breakpoint is the first breakpoint in the list file being displayed, then the debugger70selects and displays the last breakpoint in the list file corresponding to the microcode executed by a previous packet engine4a,4b. . .4n, i.e., microengine, according to a packet4a,4b. . .4nordering.Previous breakpoint in microengine 118: the debugger70selects a previous breakpoint in the list file being displayed in the panel100if there is a previous breakpoint. If the current selected breakpoint is the first breakpoint in the list file, then the debugger70selects and displays the last breakpoint in the current list file being displayed.

FIGS. 7,8, and9illustrate operations to navigate through breakpoints, which may be performed by the debugger program70that is part of an integrated development tool, e.g.,22. With respect toFIG. 7, a user interface is rendered (at block150) to display at least one program corresponding to at least one object file being executed in a debugging mode. As discussed, the displayed program may comprise compiled or assembled code corresponding to the object or executable code being executed, such as a list file. The code being executed may be executed by a simulator implementing a simulation environment of one or more processors, e.g., packet engines4a,4b. . .4n, or be executed by actual processors, e.g., packet engines in a network processor, being monitored by the debugger. The debugger70maintains (at block152) a list of breakpoints, e.g., global breakpoint list78. The breakpoint list may include, such as shown in the breakpoint entry80ofFIG. 5, the name of the program84, e.g., list file, including the breakpoint, a line number88, and a processor or packet engine86executing the executable code corresponding to the program including the breakpoint. The code from one program including a selected first breakpoint is rendered (at block154). The code may be rendered in a user interface panel, such as the debugger user interface panel100(FIG. 6), that provides a breakpoint indicator, e.g.,102a,102bof the breakpoint and execution indicator, e.g.,104, of the list file code currently executed. In response to receiving (at block156) user input to access a second breakpoint, which may comprise a selected next or previous breakpoint, the debugger70selects (at block158) from the list, e.g.,78, the second breakpoint in one of the programs, i.e., compiled list file programs. The debugger renders (at block160) code from one program including the selected second breakpoint. The second breakpoint may be included in the program including the current code being rendered or in another program not rendered in a user interface.

FIG. 8illustrates operations performed by a debugger, e.g.,78, debugging code in multiple programs, such as compiled programs, e.g., list files34, that are executed by a simulated or real processor, e.g., packet engines, being monitored in debugging mode. The processors or packet engines may execute the programs, i.e., list files or compiled programs, assigned to that processor in different threads. The debugger70renders (at block200) a user interface, e.g.,100(FIG. 6), enabled to display programs, e.g., list file84, being executed in a debugging mode, wherein there are a plurality of programs capable of being executed in the debugging mode. In certain embodiments, the programs, e.g., list files, or threads executing the list files are ordered with respect to each other. The program ordering may be dependent on the ordering of processors executing the programs, or some other ordering of the programs. The debugger, e.g.,70, maintains (at block202) a list of breakpoints, e.g.,78, in the programs. Code from a first program, e.g., list file34, including a selected first breakpoint is rendered (at block204).

If the debugger receives (at block206) user input to move to a next breakpoint when the selected first breakpoint is a last positioned breakpoint in the first program, then the debugger selects (at block208) from the list a second breakpoint comprising a first positioned breakpoint in a second program, wherein the second program follows the first program in the ordering. In this way, the debugger automatically traverses breakpoints in different programs, such as the list files34, being executed by the simulated or real processors, e.g., packet engines4a,4b. . .4n, monitored by the debugger. In the navigation menu110inFIG. 6, control proceeds to a next breakpoint in the same or another list file34upon selecting the “next breakpoint” items form the menu.

If the debugger receives (at block210) user input to move to a previous breakpoint when the selected first breakpoint is a first breakpoint in the first program, then the debugger selects (at block212) from the list a second breakpoint comprising a last positioned breakpoint in a second program. The second program precedes the first program in the ordering. In the navigation menu110inFIG. 6, control proceeds to a previous breakpoint in the same or another list file34upon selecting the “next breakpoint” items form the menu. The code from the second program including the selected second breakpoint is rendered (at block214).

FIG. 9illustrates operations performed by a debugger70debugging code being executed by multiple processors, whether real or simulated, such as in the implementation ofFIG. 4where the debugger70monitors the execution of microcode6a,6b. . .6nby multiple package engines4a,4b. . .4n. The debugger70renders (at block250) a user interface, e.g.,100(FIG. 6), enabled to display programs corresponding to executable code in a debugging mode, wherein there are a plurality of programs capable of being executed in the debugging mode corresponding to executable code loaded into multiple processors, e.g., package engine4a,4b. . .4n. The processors may be ordered with respect to each other. For instance, package engines4a,4b. . .4nmay have an ordering so that the debugger70can select among the packet engines4a,4b. . .4nin the ordering. The debugger70maintains (at block252) a list, such as the global breakpoint list78, of breakpoints in the programs, e.g., list files84. As discussed, the entries80(FIG. 5) in this breakpoint list may indicate a breakpoint number82, a list file84or compiled program including the breakpoint, the packet engine86executing the code including the breakpoint, and the line number88in the list file84of the breakpoint. The debugger78renders (at block254) code from a first program, e.g., list file84, including a selected first breakpoint, wherein the first program corresponds to executable code, e.g., microcode6a,6b. . .6n, executed by a first processor, e.g., packet engine4a,4b. . .4n. The list file may be executed by a particular thread in the first processor. The processor, e.g., packet engine, executing the code may comprise a simulated processor or a real processor.

If the debugger70receives (at block256) user input to move to a next breakpoint when the selected first breakpoint is a last positioned breakpoint in the first program, then the debugger selects (at block208) from the list a second breakpoint comprising a first positioned breakpoint in a second program corresponding to second executable code executed by a second processor, where the second processor follows the first processor in the ordering. In the embodiment ofFIG. 6, the input to move to a next breakpoint in another program, e.g., list file, executed by another processor, e.g., packet engine, is provided upon selection of the “next breakpoint in project” command in the breakpoint navigation menu110(FIG. 6).

If (at block260) the debugger, e.g.,70, receives user input to move to a previous breakpoint when the selected first breakpoint is a first breakpoint in the first program, then the debugger selects (at block262) from the list a second breakpoint comprising a last positioned breakpoint in the second program, where the second program precedes the first program in the ordering. The code from the second program including the selected second breakpoint is rendered, such as in the debugger user interface100. In the embodiment ofFIG. 6, the input to move to a previous breakpoint in another program, e.g., list file, executed by another processor, e.g., packet engine, is provided upon user selection of the “previous breakpoint in project” command in the breakpoint navigation menu110(FIG. 6).

FIG. 10illustrates an example of a network processor300. The network processor300shown is an Intel® Internet eXchange network Processor (IXP). Other network processors feature different designs. The network processor300shown features a collection of packet engines304, also known as microengines programmable engines, etc. The packet engines304may be Reduced Instruction Set Computing (RISC) processors tailored for packet processing. For example, the packet engines304may not include floating point instructions or instructions for integer multiplication or division commonly provided by general purpose processors. The network processor300components may be implemented on a single integrated circuit die.

An individual packet engine304may offer multiple threads. For example, the multi-threading capability of the packet engines304may be supported by hardware that reserves different registers for different threads and can quickly swap thread contexts. In addition to accessing shared memory, a packet engine may also feature local memory and a content addressable memory (CAM). The packet engines304may communicate with neighboring processors304, for example, using neighbor registers wired to the adjacent engine(s) or via shared memory.

The network processor300also includes a core processor310(e.g., a StrongARM® XScale®) that is often programmed to perform “control plane” tasks involved in network operations. (StrongARM and XScale are registered trademarks of Intel Corporation). The core processor310, however, may also handle “data plane” tasks and may provide additional packet processing threads.

As shown, the network processor300also features interfaces302that can carry packets between the processor300and other network components. For example, the processor300can feature a switch fabric interface302(e.g., a CSIX interface) that enables the processor300to transmit a packet to other processor(s) or circuitry connected to the fabric. The processor300can also feature an interface302(e.g., a System Packet Interface Level 4 (SPI-4) interface) that enables to the processor300to communicate with physical layer (PHY) and/or link layer devices. The processor300also includes an interface308(e.g., a Peripheral Component Interconnect (PCI) bus interface) for communicating, for example, with a host. As shown, the processor300also includes other components shared by the engines such as memory controllers306,312, a hash engine, and scratch pad memory.

FIG. 11depicts a network device incorporating techniques described above. As shown, the device features a collection of line cards400(“blades”) interconnected by a switch fabric410(e.g., a crossbar or shared memory switch fabric). The switch fabric, for example, may conform to CSIX or other fabric technologies such as HyperTransport, Infiniband, PCI-X, Packet-Over-Synchronous Optical Network (SONET), RapidIO, and Utopia. CSIX is described in the publication “CSIX-L1: Common Switch Interface Specification-L1”, Version 1.0, published August, 2000 by CSIX; HyperTransport is described in the publication “HyperTransport I/O Link Specification”, Rev. 1.03, published by the HyperTransport Tech. Consort., October, 2001; InfiniBand is described in the publication “InfiniBand Architecture, Specification Volume 1”, Release 1.1, published by the InfiniBand trade association, November 2002; PCI-X is described in the publication PCI-X 2.0 Specification by PCI-SIG; SONET is described in the publication “Synchronous Optical Network (SONET)-Basic Description including Multiplex Structure, Rates and Formats,” document no. T1X 1.5 by ANSI (Jan. 2001); RapidIO is described in the publication “RapidIO Interconnect Specification”, Rev. 1.2, published by RapidIO Trade Ass'n, June 2002; and Utopia is described in the publication “UTOPIA: Specification Level 1, Version 2.01”, published by the ATM Forum Tech. Comm., Mar., 1994.

Individual line cards (e.g.,400a) include one or more physical layer (PHY) devices402(e.g., optic, wire, and wireless PHYs) that handle communication over network connections. The PHYs translate between the physical signals carried by different network mediums and the bits (e.g., “0”-s and “1”-s) used by digital systems. The line cards400may also include framer devices (e.g., Ethernet, Synchronous Optic Network (SONET), High-Level Data Link (HDLC) framers or other “layer2” devices)404that can perform operations on frames such as error detection and/or correction. The line cards400shown also include one or more network processors406or integrated circuits (e.g., ASICs) that perform packet processing operations for packets received via the PHY(s)400and direct the packets, via the switch fabric410, to a line card providing the selected egress interface. Potentially, the network processor(s)406may perform “layer2” duties instead of the framer devices404and the network processor operations described herein.

WhileFIGS. 1,10and11describe a network processor and a device incorporating network processors, the techniques may be implemented in other hardware, firmware, and/or software. For example, the techniques may be implemented in integrated circuits (e.g., Application Specific Integrated Circuits (ASICs), Gate Arrays, and so forth). Additionally, the techniques may be applied to a wide variety of networking protocols at different levels in a protocol stack and in a wide variety of network devices (e.g., a router, switch, bridge, hub, traffic generator, and so forth).

Additional Embodiment Details

The described operations may be performed by circuitry, where “circuitry” refers to either hardware or software or a combination thereof. The circuitry for performing the operations of the described embodiments may comprise a hardware device, such as an integrated circuit chip, Programmable Gate Array (PGA), Application Specific Integrated Circuit (ASIC), etc. The circuitry may also comprise a processor component, such as an integrated circuit, and code in a computer readable medium, such as memory, wherein the code is executed by the processor to perform the operations of the described embodiments.

In certain embodiments, the debugger was used to monitor and debug the execution of code by one or more packet engines, e.g., microengines of a network processor. In additional embodiments, the debugger operations to view breakpoints may perform debugging operations with respect to the execution of code by different types of processors, including central processing units, Input/Output controllers, storage controllers, video controllers, etc. Further, the debugging operations to navigate breakpoint may be performed with respect to a single programmable processor executing code corresponding to one or more programs.

In the described embodiments, a GUI type interface was used to allow the user to navigate to a next or previous breakpoint. In alternative embodiments, the user may use keyboard commands to invoke the breakpoint navigation operations.

The list file may comprise compiled or translated file, or flat files, initially coded in programming languages known in the art, including C, assembly language, etc. In yet alternative embodiments, the code from the source file corresponding to the code being executed may be displayed in the debugger user interface, instead of a compiled or translated program, e.g., the list file34.

In described embodiments, the microcode is executed by packet engines in a simulated execution environment. In alternative embodiments, the debugger program may monitor the execution of the microcode by actual packet engines in a network processor test device.

The term packet was sometimes used in the above description to refer to a packet conforming to a network communication protocol. However, a packet may also be a frame, fragment, ATM cell, and so forth, depending on the network technology being used. Alternatively, a packet may refer to a unit of data transferred from devices other than network devices, such as storage controllers, printer controllers, etc. In such alternative implementations, the key from the header for such alternative packets may include information that is not related to the transmission of a packet over a network.

Preferably, the threads are implemented in computer programs such as a high level procedural or object oriented programming language. However, the program(s) can be implemented in assembly or machine language if desired. The language may be compiled or interpreted. Additionally, these techniques may be used in a wide variety of networking environments.

The foregoing description of various embodiments has been presented for the purposes of illustration and description. It is not intended to be exhaustive or to limit the embodiments to the precise form disclosed. Many modifications and variations are possible in light of the above teaching.