CA2153075A1 - Tool and method for diagnosing and correcting errors in a computer program - Google Patents
Tool and method for diagnosing and correcting errors in a computer programInfo
- Publication number
- CA2153075A1 CA2153075A1 CA002153075A CA2153075A CA2153075A1 CA 2153075 A1 CA2153075 A1 CA 2153075A1 CA 002153075 A CA002153075 A CA 002153075A CA 2153075 A CA2153075 A CA 2153075A CA 2153075 A1 CA2153075 A1 CA 2153075A1
- Authority
- CA
- Canada
- Prior art keywords
- program
- call
- graphical
- debug command
- computer
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Abandoned
Links
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/36—Preventing errors by testing or debugging software
- G06F11/3664—Environments for testing or debugging software
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/30—Monitoring
- G06F11/32—Monitoring with visual or acoustical indication of the functioning of the machine
- G06F11/323—Visualisation of programs or trace data
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/36—Preventing errors by testing or debugging software
- G06F11/3604—Software analysis for verifying properties of programs
- G06F11/3612—Software analysis for verifying properties of programs by runtime analysis
Abstract
In a computer system, an improved tool and method for debugging complex computer programs is disclosed. The tool extracts critical debugging information from computer memory and/or remote storage memory and uses this information to graphically depict call relationships among various functions comprising the program which is the subject of the debugging operation. Debug commands are accepted by the tool through a graphical user interface using operations performed by the user directly on the graphical representation of program functions. The ability of the tool to accept user commands through the graphical user interface and to display critical debugging information using this same interface greatly facilitates program debugging.
Description
21~307S
TOOL ANI~ MEIHOD FOR l)~AGNO.~hlG Al~ID CORRECrlNG ERRO!~
lN A COMPUTER PROGRAM
S Ihis appli~tion incllldes appel ~lic~s titled: A~ en~l;. A -microfiche copy of "Source Code for Re~ling Object Code ro~ at and Graph Layout Algolill~ having 324 fiche with a total of 4 frames; and AppendLx B - microfiche copy of Source Code for a Computer Sorlware Model of the Debugging System" having 431 fiche with a total of 5 frames.
A portion of the disclosure of this patent do~lment cont~inc material which is subject to copyright protection The copyright owner has no objection to the f~csimile reproduction by anyone of the patent doc~lment or the patent disclosure, as it al,~ea~s in the Patent and Tr~dem~rk Office patent file or records, but otherwise reserves all copyrights whatsoever.
BACKGROUND OF THE INVE~TION
L I~IELD OF THE INVENTION
This invention relates to a system and method for locating and correcting errors in a computer program and, more particularly, to a system and method for graphically displaying the structure of a program and controlling the execution of the program during the software debugging process.
21~307~
TOOL ANI~ MEIHOD FOR l)~AGNO.~hlG Al~ID CORRECrlNG ERRO!~
lN A COMPUTER PROGRAM
S Ihis appli~tion incllldes appel ~lic~s titled: A~ en~l;. A -microfiche copy of "Source Code for Re~ling Object Code ro~ at and Graph Layout Algolill~ having 324 fiche with a total of 4 frames; and AppendLx B - microfiche copy of Source Code for a Computer Sorlware Model of the Debugging System" having 431 fiche with a total of 5 frames.
A portion of the disclosure of this patent do~lment cont~inc material which is subject to copyright protection The copyright owner has no objection to the f~csimile reproduction by anyone of the patent doc~lment or the patent disclosure, as it al,~ea~s in the Patent and Tr~dem~rk Office patent file or records, but otherwise reserves all copyrights whatsoever.
BACKGROUND OF THE INVE~TION
L I~IELD OF THE INVENTION
This invention relates to a system and method for locating and correcting errors in a computer program and, more particularly, to a system and method for graphically displaying the structure of a program and controlling the execution of the program during the software debugging process.
21~307~
2. n~-~CRIP'llON OF REI~TED ART
Newly created c~n~puter pro~s often in~lude one or more inad~ellent errors. Some software errors can result in the complete failure of a sorl~re system, while others may result in illC'Ol~C~l S behavior. Although commercial sonware developers will typically devote 50-70% of their total development time to cl~ecL ;.~ the oo~ uler ~,ro~l for errors and COl-e~li(lg those errors, it is almost inevitable that some errors ("bugsn) remain even in pro~uctiQn versions of the software rele~ce~ to the public. There is, therefore, a great need for an efficient and effective means for "debugging" software.
Debugging is the process of identifying and icol~ting a software error so that the problem can be corrected. Usually this involves eY~mining the lines of code co~ g the sorl~e program and/or observing the program's execution to determine the cause for the LS abellalll behavior.
In the prior art of debugging a program, a user may first read the program line-by-line to try to locate the error or errors. Ho~e~er, following the flow of a program by reading it line-by-line can be extremely difficult and time concuming~ even in a relatively simple program. If the program contains many loops, subroutines, function calls, variables and the like, the user may not be able to trace the sequence of program execution, and hence may not be able to determine the effect of the execution of each line of the computer program.
"Debuggers" are softvare tliagnostic tools that provide users with mech~nism~ for viewing and controlling the execution of programs (inchlding the program states and the values of variables) for the purpose of helping the user identify errors in the program code. With prior art debuggers, the user can control the operation of the defective - - 21~307~
software program by inpulli,lg one or more debug co.. z.-~lc and observing the results of the subsequent pfOg~ u cYe~ltion- For e~ ple, a debugger co~ may be invoked to set a "break point" at a loc~tion in the defective program. The effect of a break point is to S suspend program eYec~bon when the location of the break point is rcn~h~ The user can then cause the dcl,uE,~er to display the values of sel~cte~ variables. State-of-the-art debuggers can also display several lines of ~ csemhled , ~hine code and/or the ~ol,~spon~ lines of source code o~u~ling before and after the break point. Even state-of-the-art debuggers, however, do not predict where and whether a program will branch. Therefore, a deficiency in current state-of-the-art debuggers is that the lines of code which they display following the point of suspension are simply the next concec~ltively numbered lines of code in the program. Such lines of code may not necess~.ily be the code which will be eYec~1te~1 when the user re~.. es operation of the ~1 Og~lL
Typical debug comm~n~ls include: a "step comm~n-l," in which the program is executed one line at a time, with the lines of code possibly being displayed as they are executed; a "watch value command,"
which displays the c~l~nging value of a selected variable while the program is running; a "trace comm~n~l~" which displays a list of active functions on the stack; a "data break comm~nd" which stops execution of the program upon the occurrence of a user-selected condition, such as a variable achieving a predetermined value; and an "assign comm~nd," which assigns a user-selected value to a variable.
Notwithst~nding the wide-spread use of debuggers, debugging can still be difficult and time co.,~...;ng One reason for this is that prior art debuggers are text-based, i.e., the debuggers provide the user with information in the form of a series of lines of text and accept comm~n~lc in a similar format. For example, with prior art debuggers 215307~
the user may type in an instruction which causes the debugger to place a break point in a particular line of a l)ro~ or, using a mouse, "point and click" on a line of code to place a break point at the be~,-n~ng of that line. Upon t_e oc~.;ullencc of the break point, prior art debuggers S can display lines of te t containinE the lica~çmhle~l m~rhine codeeYecuted up to the break point, the colles~o~ding line or lines of source code and the value of certain selected variables.
The operation of a dc~ugger at this text-based level has numerous disadvantages. For example, the user must be intim~tely famili~r with the orga~ tion of the program being debugged, since the debugger can only display the lines of code colllylising the execution path actually traversed by the program; the debugger cannot tell the user which alternative execution paths could have been taken by the program using a different set of input data Prior art debuggers also do not tell the user which fi~nction~ could be called by the particular function located at the break point. The user must deduce this information by eY~mininE the displayed code. Thus, to fully appreciate the state of the program at the break point, the user must figure out and retain a complex mental picture of the various execution paths which the prograrn n~ight have taken to have reached its current state and the various execution paths it might take once the next debug command causes program execution to resume.
Users of prior art debuggers frequently find themselves in a situation somewhat analogous to a cross-coun~l~ traveller without a road map who, upon re~hing each successive intersection, must ask for the name of the closest town in each direction. Without a road map showing all the roads that lie between the embarkation point and his or her ~lestin~tion~ the traveller cannot plan the most efficient way to get to the ~lltim~te destination. ~ncte~(l, using only trial and error, the 21S3 07~
traveller can easily get lost, may have to backtrack and will frequently find himc-elf or herself going down dead end streets.
Despite many ad~ances in deblleging terhnology, clcaling defect-free sofl .are is an elusive goal that is far from being achieved.
In fact, t_e trend toward incleaSin~ COmple% SOflware ~le~s _ akes achieving this goal even more difficult. Thus, the de~..gger is one of the most hll~ol~nt tools affecting a pro~cl's productivity. It is swlJlising therefore, that despite the conc;derable effort which the software industry has devoted to debuggers, their use is still so cumbersome. (The ill~enlo,~ believe that this results from the fact that prior art debuggers are based upon a model that was developed to support traditional character-based termin~lc-~) In view of the above, it is clear that there exists a need for an hllpro~ed debugging tool. In particular, there exists a need for a debugging tool that can abstract critical debugging il~o,lllation from increasingly complex software, display that information in a dynamic and useful graphical format and, in addition, allow the user to control program execution through operations performed directly on the graphical representation of the program.
2153~7~
.';UMl'MRY OF THE INVENTION
The pres~lll invention provides an illlyro.cd debugger having a graphical user interface. The debugger preferably operates in a client-server Co~ g e~ on~ nt A portion of the debugger, here-n~ler rerelled to as the "debugger server," ~refe.ably eYecutes on the same server colllpuler as the progl~ which is to be debugged. The debugger server rece;~es debug comm~n~lc tlanslllilled from the client colllyuler and, in cooperation with the server's operating system, eYec~ltes these co~ ndc The debugger reads certain inrol,llation, called "syrnbolic information," which is typically stored in the server colll~uler's memory or on an ~csoci~ted magnetic disk storage subsystem. The debugger server also reads program state information from that coull~uter's Illelllol~. Using the symbolic information, the debugger server derives the "call rel~tionchips" between the functions cont~ined within the program, i.e., which functions can call which other functions. The server computer then transmits this information, along with the cul-en~
program state, to the client computer.
A graphical user interface portion of the debugger is preferably resident on the client computer. This portion of the debugger receives the call relationship information and program state information led from the server. Using this inrollllalion, the user interface constructs and displays a graph of the functions col,-~,lising the program which is to be debugged. For example, the debugger could display a tree-like graphical representation of the program, wherein each function colllyli.ing the program is represented by a node on the graph and the call re!~tionships bet veen functions are illustrated by lines interconnecting the nodes. Such a graph is known as a "call treen.
-The interface of the present invention displays the call tree in several user selected folll-ats. This tree serves as a "road map" for debugging, allowing the user to easily determine the set of po~cible eYecution paths that the program may take in the future. The interface S also a~otates the call tree with addition~ rol.. ~l;Qn, such as th-e values of user-selected variables, hj~hlighting the ~iullent eYec~ltion path as detell.-ined from the function call stack, and in~li~ting, in any coll~eaient way, when a break point is set in a f~ln~ion The interf~ce also provides debugging co.. )~ lC that can be applied to the functions represented by call tree nodes. These comm~nds in(lude the ability to step program execution a function at a time, the ability to view the source code associated with a function, the ability to set a break point on a function, and the ability to "eYp~nll" and "collapse" call tree nodes, as will be discussed later in greater detail. The interface tr~nsnniLc these comm~n~ls to the server col,~puter for eYec~tion.
The user may enter debug commands into the client compuler in the traditional m~nner by typing commands on an associated keyboard. Alternatively, however, and in accordance with an important aspect of the present invention, the user may control the functioning of the debugger and enter debug comm~nds directly through the graphical interface simply by using a mouse to point and click, first directly on the node shown on the displayed call tree whereat the comm~nd is to be executed and then on a graphical symbol, such as an icon or menu item, for the desired debug comm;q~nd The ability of the present invention to graphically represent debugging inrol.llation and accept debug comm~nds through a graphical interface greatly facilitates the software debugging process. In particular, the ability of the debugger of the present invention to display a call graph with indications along the call graph showing the last function exec~ted, all prior functions eYec~lte~i and all functions which 2153~7~
could be called from the point where program eYec~ltion is suspended greatly erlh~nces the user's ability to more thoroughly and easily understand the ~ e.ll state of the l,ro~L
In relation to the analogy of the cross~ounl~ traveler descnbed S previously, the lJreSen~ invention is equivalent to providing the lla~eler with a complete road map of all highways and surface streets l~h.~ll the e~b~ation point and the ultim~te destin~tion Such a road map allows the traveler to assess the best possible means to reach a particular destin~tion. By analogy, the present invention provides the same type of road map to the programmer and allows him or her to assess the best and most efficient means to debug a program.
These and other advantages of the present invention will become more fully apparent when the following detailed descriptions of the invention are read in conjunction with the ~cco.,.p~..ying dra~
BRIEF Dl;~CRIPI'ION OF THE DRAVVING~
The invention will now be described with reference to the ?^c4~p~ rin~, d-a~ ~, wherein:
Fig. I is a block diagram of a client/server colllplltill~, system S for c~,~ g out a l)refe-led embodim~nt of the ~rese,ll invention.
Fig. 2 illustrates memory org~ni7~tion of the stack within the server colllp-~ler.
Fig. 3 is a diagram illustrating the file o~ <iltion of a complex col..p~lter program.
Fig. 4 is a flow diagram illustrating the convelsion of source code into executable code.
Fig. S is a diagram illustrating the structure of the symbolic information files created by the compiler for the program to be debugged.
Fig. 6 is a dynamic call tree created and displayed by the debugger of the present invention illustrating the possible execution paths of an order proces~in,~ program prior to debugging.
Figs. 7a and 7b are flow diagrams in accordance with a preferred embodiment of the present invention.
Fig. 8 is a dynamic call tree created and displayed by the debugger of the present invention illustrating the state of the example order processin~ program in which the fi~n~ion "Main" has called the f~ln~ion "Get Order" which subsequently called the fun~iQn "Verify Order," and wherein the "Verify Order" node has been e~r~nded to show its child nodes (functionc) when c~,..p~r~d to Fig. 6.
S FiB. 9 is a ~n~ic call tree created and di~pla~d by the de~!~eer of the present invention illustrating the same pro~ state as Fig. 8, but in addition, this figure shows that the Verify Order node was sele-cte~l and the user issued a comm~nd to display the source code co~ .ising the Verify Order function.
Fig. 10 is an "acyclic" call tree display of a program's or~ni7~tion generated by the debugger of the present invention.
Fig. Il is a "cyclic" call tree display of the olg~ t;on of the same program as illustrated in Fig. 10.
D~T~n ~n DF~ ON OF THE
PREFERRED EMBODIMENl~
The following description is of the best presently contemplqted modes of c&~l~ing out the invention. This description is made for the purpose of illusllaling the general principles of the invention and is not to be taken in a li.,liling sense.
As illustrated in Fig. 1, the debugger of the present invention is preferably decigre~ for use in a client/server co~l~uling envilo~,ent 100. The server con~ er 102 co.. ~nicates over a bus or I/O rh~nne 104 with an associated disk storage subsystem 106. The server compuler 102 in~ludes a CPU 108 and RAM 110 for storing current state infollnation about program execution. A portion of the RAM 110 is dedicated to storing the register states and local variables ~Csoci~te~
with each function of the program which is cullelllly executing on the server computer 102. This portion of RAM 110 is typically called a "program stack" or simply "the stack" 202 (Fig. 2). As illustrated in Fig.
2, the RAM locations, associated with information pertaining to each such function, are org~ni7ed in a data structure 200 known as a "frame".
The client colllpuler 112 (Fig. 1) similarly includes RAM 114, as~sociated disk memory 116, and a keyboard 118, a mouse 120 and a video display terminal (nVDl`') læ. The client CPU 123 coml,,unicates over a bus or I/O channel 124 with the disk storage subsystem 116 and via I/O ch~nnel 126 with the keyboard 118, VDT 122 and mouse 120.
Con~istent with the preferred client/server model, respective portions of the debugger software are preferably designed to operate simllltaneously on the client 112 and server 102 computers.
Coordination between the operations performed by the two portions of the debugger sohware are m~int~ined by communication over a networlc 128.
~ 2153Q75 As will be diccllcsed in greater detail below, most sofl- are pro~alus today are written in so called third gene.a~ion "high-level"
a~es which a con~ril~r tranCl~tes to m~ine inStr lctionc Programs written in third generation l~n~lages are or~ ed into S functions (also refe.l~1 to as proc~l~es or roulil~es). Fl~nGtionc are ~efine~ to ~Cl~ specific proc~-csin~ tasks. They are co..-~se~ of one or more lines of source code and may have their own local v~ bles which m~int~in state illfo~ tion that is unique to the funGtiQn Functions may call other functions to perform specific tasks. When this occurs, eYec~ltion transfers to the "called" function and will return to the "calling" function when the called function has completed the requested task.
The execNtion state of the program is m~int~ined on a "call stack," located within co~llputer memory, which records the current lS eYecution location in each function that has been called. When a filnr~ion is called, the current execNtion location in the calling function is recorded in the stack. When the called function completes, this location is removed from the stack and execution resumes at the saved location in the calling function.
As is known in the progr~mming art, program execution begins at the "Main~ routine and progresses as the Main routine calls other routines to perform various proces~ing tasks. These other called routines may in turn call yet additional routines. The execution state of a program at any particNlar time is represented by the program call stack.
As illustrated in Fig. 3, a typical program to be debugged, for example, an order processing program, may be composed of several source code files: (a) Main 300; (b) Input 302; (c) Proces~in~ 304; and (d) Output 306. Each source code file 300, 302, 304, 306 is composed of several functions 308. Each function 308 ~pically CQ~ of plural 21~307~
lines of source code 310 and, upon completing its task or upon the oc~ e~ce of a particular event, each f~ln~ion will either initiate (or ~caun) the operation of another fUnGtion 308, or return eYec~tion to the functiorl 308 which called it.
Before the order procescing ~ro~ can be run on the co~puler 102, its source code files 300, 302~ 304, 306 must be "con~riledn. Compilation ~on~elb the human-readable source code 310 into a binany code, called "object coden. Many commercially available compilers may be used in connection with the present invention. For example, a Tandem C compiler from Tandem Computers Incol~,olated of Cupertino, California may be used. This compiler generates object files in Common Object File Format ("COFFn). Many UNIX compilers also generate COFF files. The use of any particular compiler is not important to the present invention, as long as the compiler produces the .. ec~-ss~y information for use by the debugger of the present invention, as described herein.
As illustrated in Fig. 4, the compiler 410 co~ e,~ each source code file 300, 302, 304, 306 into an object code file 400, 402, 404, 406.
In addition to tr~nsl~tin~ the source code into binary coln~uter instructions, the user can also instruct the compiler 410 to include a significant amount of additional information, called "symbolic information," in each object code file 400, 402, 404, 406. The symbolic inforrnation include-s, for example, variable names, function names, variable addresses and lists of all locations within the object code file where one function calls another function. Of particular interest, with respect to the operation of the present invention, is that portion of the symbolic information from which the debugger can determine the hiel~rcl ial call relationships between the various functions 308, i.e., which f~ln~ionc 308 can call which other f~ln~ion~ 308. The symbolic i~ltul~ation typically forms a portion of each object file 400, 402, 404, 21~3 ~7S
406 stored in the con~puler's memory 110. Altcrllali~ely~ however, the symbolic inrollllation may be stored in a separate Sle located in the disk storage subsystem 106. As will be explained below, the pl~ use for the symbolic infollnation is in debugging the eYecutable plO~L
S Fig. S illustrates the structure of two typical object code files 500, 502. The Header section 504 of each file co.~ c pointers to the starting locations of the various sections of the file, for rY~mpl~, the Header section co~ u the file offset for the Fix-up Table. The Static Data section 506 of each file contains all of the co-~l~t values used by the program. The Instruction Code section 508 of each file CQ~ the actual binary coded instructions for eYecuting the program. The Function Entry Point Table 510 of each file contains a list of functions which reside in the associated file and the addresses of each such f~nction The Fix-up Tables 512 are lists of addresses within each associated file where one function 308 calls another function 308. Each Unresolved External References Table 514 contains a list of all functions 308 which are referenced within that file but are ~le-fined elsewhere.
All of the object code files are ultimately provided to a "linkerH
412 (Fig. 4). The linker 412 is a software program which combines or "links" the various object files 400, 402, 404, 406 into a program 414 that can be executed by the computer 102. An important function of the linker 412 is to read the Function Entry Point Table 510, the Fix-up Table 512 and the Unresolved References Table 514 of each object code file 400, 402, 4û4, 406. The information collectively cont~ine~l in these three tables is sufficient to enable the linker 412 to produce an executable code file 414 having the same data structure illustrated in Fig. S and all nece-ss~r references or logical connection~ 516 (Fig. 5) between the various functions originally residing in all of the object code files 400, 4û2, 404, 406 co~ ising the program.
Although the use of a compiler which generates object code files using the COFF st~nd~rd is not required by the present invention, if such a compiler is used, then the Tandem C~rnputers Incol~oraled Native Linker/Loader could be used to link the object code files.
S Alte~nali~.ely, any lillker that can process other object file fo~als could be used. Again, the use of any particular linker or any particular file format is not important to the present invention as long as the i~ollllalion ,-ecess~ to the operation of the present ill~e, debugger, as set forth herein, is provided.
During eY~cutio~ of the program, the server coll~uler 102 ...~inl~in~ il,çoll~ation in its memory 110, called "state information." As implied by the name, the state information is all inform~tion needed to ~co~ uct the c.lllenl state of the CPU 108. The state inform~tion includes the stack 202 (Fig. 2). In the usual case, this inform~tion is .,.~ i"ed as a linked 204 list of frames 200 within main memory 110.
As is known in the art, a stack pointer identif;es the function within the linked list currently being executed by the computer 102.
The debugger server reads the symbolic information stored within the server computer's memory 110 or on disk 106. As will be apparent &om the foregoing discussion, by reading the Function Entry Point tables 510, as supplemented by the linker 412 for references 516 to functions in other object code files and the Fix-up tables 512, the debugger can obtain all the information necessary to create a complete call graph for the example order processing application program (or any other program being debugged). Alternatively, in the particular instance where the debugger is operating on COFF files, where the COFF
standard does not incl~lde a Fix-up Table, then the debugger is simply pro~ -ed to synthe-si7ed Fix-up Table information by searching the m~ine instruction code for all addresses where one function calls another.
- 21!~307~
Fig. 6 illustrates such a call graph for the example order proce-scing program. Each of the twelve nodes 600 in the figure reprere,lls a particular funrtion inrlude~l within the overall PrO~L
The lines 602 connec~ the nodes 600 indicate that the left-most S fun~i~n may call the function to the right. For ~ , as set forth inthis figure, the main program f~ln~ion can initi~te calls to r~ ;O.~
(nodes) which get the order, update the d~t~b~ce, print an invoice, etc.
Each such function 600, in turn, calls sllbcidiary functions which carly out the physical steps of y~ ;n~ a visual display on the co~puler terminaL reading user input, etc.
The debugger server also reads the stack llfo~ ation from the target program's address space in the memory 110 of the server coll~ùter 102 and determines the state of the stack 202. As will be understood by those skilled in the art based upon the fcrgohlg lS ~i.cCuccion, typically, a co,l")uler has a dedicated stack pointer register or uses a general purpose register as a stack pointer. The debugger of the present invention uses the stack pointer to find the first stack frame 200. Since all stack frames are linked 204, the debugger can then easily locate the rem~ining frames. After having read the symbolic information, derived the information necessary to create a call graph as explained above and obtained the stack information, the server then transmits the call graph and stack information to the client computer 112.
The preferred embo(liment of the present invention in~ludes 2S graphical interface software resident on the client co",p,ller 112. The graphical interface software displays debugging information on the VDT
122 and receives debug comm~ntlc from the user, either via the keyboard 118 or by input from a mouse 120 operating a moveable curser or pointer 606 (Fig. 6) on the VDT 118 in a known fashion.
2ls3a7s The graphical interface software preferably incll)des as a portion thereof an off-the-shelf graphics soflware package, such as, for eA~Il~le~ Microsoft Windows, available &om Microsoft Col~olalion of Re-lmon~, W-qchineton~ or zApp Application Framework available &om Inmark Development Col~olalion of Mountvin View, Cqliforn;q Similar commercially available graphics soflware p~ages, c~pq~l~ of creating graphical d,awill~s and pe,rolming user interactions as described herein, may also be used.
Using established algolitlllns such as, for example, the "Sugiyama Algorithm", disclosed in "Methods for Visual Understqn~1in~
of Hierarchial Systems Structures", by Kow Sugiyama, Shojiro Tagawa and l~5itcuhiko Toda in IEEE Transactions On Systems, Man and ~ybernetics. Vol. SMC-11, No. 2, Februa~y, 1981, pgs. 109-125; Thesis:
Michael B. Davis, "A Layout Algorithm for A Graph Browsern, ~,~
Berkeley Engineering Library; or "A Browser for Directed Graphsn, by Lawrence W. Rowe, Michael Davis, Ely Messenger, Carl Meyer, Charles Spirakis and Alan Tuan, U.C. Berkeley Fn~ineerin~ Library.
and the call graph information transmitted from the server, the client constructs a visual rendering of the call graph on the VD,T 122. Using the stack information transmitted from the server, the client highlight5 particular portions of the rendering to indicate the execution path taken by the program.
Each of the above-identified references is incorporated herein by reference as non-essential subject matter; other known graphing algorithms may be substituted into the debugger of the present invention in place of the Sugiyama algorithm or the Davis modification of that algolilhlll.
The debugger operates according to the process steps illustrated in Figs. 7a and 7b. As seen in these figures, the ~loglalll to be debugged can be started under the control of the debugger l~r~ l 700 21~307~
or by tbe operating syctem wbich subsequently calls the deb~l~ger 702.
In either event, tbe application program is loaded into the server colll~ er's memory 110 and comes under control of the debugger server. Tbe debugger tben readc tbe symbolic inroln-~t;on 704 from tbe S server co,nputer's memory 110 or associated disk subsystem 106, derives tbe call grapb relationchips among tbe various fimCtions 706 and reads tbe frame illfol...al;on and pointer inlcl,nalion from tbe server llle,uol~
708. Tbe server then tr~ncmi~C this i~fol..~tion over tbe lletWUl~ 128 to tbe debugger client 710.
Baced upon the information transmitted from the server to the client, the graphical interface soflware residing on the client compuler 112, using the Davis enhancement to the Sugiyama algorilhlll, constructs 712, 714 and displays 716 a call graph of the program being debugged.
Since the frarne stack information is also tr~nsmitted to the client, the debugger determines and highlights the execution path of the progr~
on the call graph. Fig. 6 illustrates the call graph rendered before the debugger initiates prograrn execution. Note that, in this figure, only nMAINI~ is highlighte-l, thereby indicating that the program is ready to execute.
Utilizing the mouse 12Q the user inputs a debug cQmm~nd 718.
For example, the graphical interface software could be de-si~ed to accept comm~ntls using the "point and drag" and/or "point and click"
metho~s According to the point and drag method, a plurality of symbols representing the various debug co-lmlallds, for example, as shown in Fig. 6 at 604, may be displayed across the top of the VDT
screen 122 as a Debug Comm~nd Toolbar. The user selects an object and a comm~nd to operate on that object by manipulating the mouse 120 to move a curser or pointer 606 displayed on the VDT screen 122 until it points to the location on the call graph where the debug cotnm~nd is to be eYec~lted The user then presses the button on the 215307~
mouse, moves the mouse 120 until the pointer 606 points to the location on the c~ nd tool bar 604 displaying the icon for the desired debug co~n~ nd and releases the button. The "point and click" ~thod is similar, except that the button on the mouse 120 is pressed and r~k~l S while the poinler 606 is poi~liug to the loc~tiQn on the call graph where the co-.~ l is to be ~Yecute~l The pointer 606is then moved to the location along the toolbar 604 where the desired debug co~ d icon is located and the button on the mouse 120 is pressed and released a second time. Both methods for in~ull.ng co.. ~ 1c to general purpose co~p,llers are well known in the art.
In either event, the client then tr~ncmitC the debug comm~ncl to the debugger server, thereby c~using the order proceccin~ program to eYecute in accordance with that comm~n~ and under control of the debugger. For eY~mple, with reference to Fig. 8, if the debug comm~n~
was the entry of a break point at Verify Order 808, the program would execute up to that breakpoint. Upon re~rhing the breakpoint, the server portion of the debugger reads the frame info~ ation and transmits the current state of the program to the client. Upon receipt of this information, the client alters the display by hiehlighting the execution path followed by the program up to the break point at the Verify Order function 808. Fig. 8 illustrates the graphical user interface display at such an intermediate step in the debugging process.
Note that, by highlightinp the execution path on the displayed call graph, the invention provides the user with an easily understood graphical display showing, not only the alternative paths the prograrn could travel when the program is allowed to continue ~ ;n~" but also the execution path already traveled by the program. As previously mentioned, the values of selected variables 800 at the time the break point is encountered may also be displayed.
~15307~
If the user locates the bug based upon the displayed il~folulalion, the user then ~lrecls the error in the source program, reco~ .iles, re-links and restarts the progr~L Alternatively, if the bug is not located, then the user inputs another debug c~ d This l,loc~ es and SI~CC~ states of the pro~ are illustrated on the graphical display (along with selecte~l variables, source code and ~lis~csembled m~chine code, as desired) until all bugs are located, corrected and the p-ogr~ul performs in the proper m~nn~r.
In the course of a debugging session, a programmer will want to concentrate his or her efforts in a particular area of the p;og~ L The present invention allows the yro~ er to hide or show necec~
program detail by allowing intermediate nodes of the call tree to be "coll~rsed" (as illustrated in Fig. 6) or "expanded" (as illustrated in Fig.
~). To allow for such a control, each node which has child nodes is provided with an icon button which functions as a switch. When a node is coll~rse~l, the child function nodes will not be displayed; when eYp~nded, the child f~lnctio~ nodes are displayed. By allowing the programmer to control the level of detail displayed, the debugger is providing the capability to control the visual complexity that the user has to deal with.
Fig. 9 illustrates a display window 900 wherein the source code corresponding to the Verify Order function 908 is displayed.
Disassembled m~rlline code (not shown) could be displayed in ad-lition or as an alternative. The source code display 900 (or, alternatively, a ~lis~csembled m~chine code display) may be obtained by issuing comm~n~lc using the same "point and click" or "point and drag"
techniques disc~lssed above. In the particular case illustrated to Fig. 9, the user fir.st points and clicks on the Verify Order node 908 and then on the Source Code View menu item located under the view menu 902 along the debug ~o.~ )d tool bar. Thus, it is apparent f~om the foregoing description that the present invention provides an e ~lle~ely simple way to locate and display lines of code ~soc~?ted with a f~n~i~n and/or to issue a debug co~ zn~l such as a breakpoint, at a r..n.~;o.~, rather than having to browse the source code in search of the first line S of the target fun~ion In the call graph view, the debugged of the presenl invention has the capability to display the call graph in two modes which we call the "acyclic" (Fig. 10) and "cyclic" (Fig. 11) modes. A cycle is ~re5e~l in a call graph when there is reculsi~e function call. A rcc.~ call exists when a function calls itself or another ~lnction that is active on the program stack 202. In esse~c~ we have a loop. The t vo modes, cyclic and acyclic, have different advantages. Fig. 10 illustrates the general case of an acyclic representation of a call graph 1000 which is rendered on the VDT screen in a top-down fashion, in which the program's top-most function (main) 1002 is at the very top and subsequent child functions are indented to the right and spaced lower in the window.
The advantage of the acyclic representation is that it is visually clear because there are no lines which cross each other since the debugged replicates the function node in all the places that it is referenced. For example, if function MAIN calls functions B, I and J, and B calls functions I and M, I will be represented twice in the acyclic view. A
possible disadvantage of this representation under certain c,r~ nces is that one loses the information about how many functions call a particular f~mction In the example of Fig. 10, it is simple to see that I
gets called by MAIN and B, but it would be difficult to visually extract this info.mation from a more complex call graph.
Fig. 11 is a cyclic representation of the same call graph 1000 as is shown in Fig. 10. Here, there is no attempt at replication of nodes, but the rendering of program structure is more complex. To display a cyclical represent~tion of the call graph, the graph is laid out in a left-21~3075 to-right f~chion where the MAIN fun~ion 1002 is at the very left and e~nCion through the child nodes occurs to the right. Sinoe there is only one in~t~nce of each fUnction node, the de~ugged must show all c~-.e~:Qnc going into and out of a single represent~tion of the particular node.
For large program. with many re~ ulsi~e caLc, the cyclical represe-~t~l;on of the call graph may get very complex. This is the reacon that the present invention offers the user an option to use either mode so that the user can view the represent~tion that provides the necess3ry information in the most understandable format.
As can be seen &om the above detailed description, the present invention greatly simplifies debugging. It is particularly useful in the debugging of complex programs bec~lse the graphical nature of the display shows the user the Of g~ tion of the program in a way which prior art text-based debuggers cannot. With the present invention, the entire call graph of the program (or a selected portion of the call graph) may be displayed, thereby providing the user, in a single display, with: (a) information relating to the overall program or~ni7~tion; (b) the current state of execution of the program; (c) the execution path taken by the program to reach its .;.llrenl state; (d) alternative execution paths the program might have taken; and (e) alternative execution paths the program could take when the program is allowed to conli~ e execution. Clearly, existing text-based debuggers cannot provide such information to the user in a single, dynamic display. These five pieces of information, displayed on a single screen in a simple graphical format, combined with the ability to enter debug romm~n-l~ by acting directly on the graphical rendering of the program, greatly f~cilit~tes the debugging process.
Several preferred embodiments of the present invention have been described. Nevertheless, it will be understood that various 215307~
modifications may be made without departing from the spirit and scope of the invention. For example, debuggers according to the prese.ll invention can be run on a sinBe colll~-lter, rather than in the preferred client-server ellviro~..cn~ While execution paths may preferably be S displayed in bold or hiehli~hted video along a call graph, wLere,ll proa;~ funrtionc are represe~ted as nodes and lines cQIlnecting the nodes depict the ability of one ~1nrtio.l to call anotller filn~i~
numerous other ways of graphically conveying ~lOE5l~l o~ ;on and execution path il~ln~ation will be apparent to those of ordh~ sldll in the art based upon the present disclosure. Thus, the present invention is not limited to the preferred embodiments described herein, but may be altered in a variety of ways which will be apparent to persons slcilled in the art.
In describing the preferred embo~limentc, a number of specific technologies used to implement the embo~lim~-nts of various aspects of the invention were identified and related to more general terms in which the invention was described. However, it should be understood that such specificity is not intended to limit the scope of the rl~imed invention.
215337~
T OF APPEN~ICF~
Ap~endi~ A - Microfiche copy of source code for reading object code files and graph layout algo~ he server portion is written in Tr~n~ion Application T ~n~)age. The client portion is written ill S C~+.) ~ pendLx B - Microfiche copy of source code for a Co,lll,uler Soflware Model of the Debugging System written in the Sm~llt~
colllpu~er l~ne~ge.
Newly created c~n~puter pro~s often in~lude one or more inad~ellent errors. Some software errors can result in the complete failure of a sorl~re system, while others may result in illC'Ol~C~l S behavior. Although commercial sonware developers will typically devote 50-70% of their total development time to cl~ecL ;.~ the oo~ uler ~,ro~l for errors and COl-e~li(lg those errors, it is almost inevitable that some errors ("bugsn) remain even in pro~uctiQn versions of the software rele~ce~ to the public. There is, therefore, a great need for an efficient and effective means for "debugging" software.
Debugging is the process of identifying and icol~ting a software error so that the problem can be corrected. Usually this involves eY~mining the lines of code co~ g the sorl~e program and/or observing the program's execution to determine the cause for the LS abellalll behavior.
In the prior art of debugging a program, a user may first read the program line-by-line to try to locate the error or errors. Ho~e~er, following the flow of a program by reading it line-by-line can be extremely difficult and time concuming~ even in a relatively simple program. If the program contains many loops, subroutines, function calls, variables and the like, the user may not be able to trace the sequence of program execution, and hence may not be able to determine the effect of the execution of each line of the computer program.
"Debuggers" are softvare tliagnostic tools that provide users with mech~nism~ for viewing and controlling the execution of programs (inchlding the program states and the values of variables) for the purpose of helping the user identify errors in the program code. With prior art debuggers, the user can control the operation of the defective - - 21~307~
software program by inpulli,lg one or more debug co.. z.-~lc and observing the results of the subsequent pfOg~ u cYe~ltion- For e~ ple, a debugger co~ may be invoked to set a "break point" at a loc~tion in the defective program. The effect of a break point is to S suspend program eYec~bon when the location of the break point is rcn~h~ The user can then cause the dcl,uE,~er to display the values of sel~cte~ variables. State-of-the-art debuggers can also display several lines of ~ csemhled , ~hine code and/or the ~ol,~spon~ lines of source code o~u~ling before and after the break point. Even state-of-the-art debuggers, however, do not predict where and whether a program will branch. Therefore, a deficiency in current state-of-the-art debuggers is that the lines of code which they display following the point of suspension are simply the next concec~ltively numbered lines of code in the program. Such lines of code may not necess~.ily be the code which will be eYec~1te~1 when the user re~.. es operation of the ~1 Og~lL
Typical debug comm~n~ls include: a "step comm~n-l," in which the program is executed one line at a time, with the lines of code possibly being displayed as they are executed; a "watch value command,"
which displays the c~l~nging value of a selected variable while the program is running; a "trace comm~n~l~" which displays a list of active functions on the stack; a "data break comm~nd" which stops execution of the program upon the occurrence of a user-selected condition, such as a variable achieving a predetermined value; and an "assign comm~nd," which assigns a user-selected value to a variable.
Notwithst~nding the wide-spread use of debuggers, debugging can still be difficult and time co.,~...;ng One reason for this is that prior art debuggers are text-based, i.e., the debuggers provide the user with information in the form of a series of lines of text and accept comm~n~lc in a similar format. For example, with prior art debuggers 215307~
the user may type in an instruction which causes the debugger to place a break point in a particular line of a l)ro~ or, using a mouse, "point and click" on a line of code to place a break point at the be~,-n~ng of that line. Upon t_e oc~.;ullencc of the break point, prior art debuggers S can display lines of te t containinE the lica~çmhle~l m~rhine codeeYecuted up to the break point, the colles~o~ding line or lines of source code and the value of certain selected variables.
The operation of a dc~ugger at this text-based level has numerous disadvantages. For example, the user must be intim~tely famili~r with the orga~ tion of the program being debugged, since the debugger can only display the lines of code colllylising the execution path actually traversed by the program; the debugger cannot tell the user which alternative execution paths could have been taken by the program using a different set of input data Prior art debuggers also do not tell the user which fi~nction~ could be called by the particular function located at the break point. The user must deduce this information by eY~mininE the displayed code. Thus, to fully appreciate the state of the program at the break point, the user must figure out and retain a complex mental picture of the various execution paths which the prograrn n~ight have taken to have reached its current state and the various execution paths it might take once the next debug command causes program execution to resume.
Users of prior art debuggers frequently find themselves in a situation somewhat analogous to a cross-coun~l~ traveller without a road map who, upon re~hing each successive intersection, must ask for the name of the closest town in each direction. Without a road map showing all the roads that lie between the embarkation point and his or her ~lestin~tion~ the traveller cannot plan the most efficient way to get to the ~lltim~te destination. ~ncte~(l, using only trial and error, the 21S3 07~
traveller can easily get lost, may have to backtrack and will frequently find himc-elf or herself going down dead end streets.
Despite many ad~ances in deblleging terhnology, clcaling defect-free sofl .are is an elusive goal that is far from being achieved.
In fact, t_e trend toward incleaSin~ COmple% SOflware ~le~s _ akes achieving this goal even more difficult. Thus, the de~..gger is one of the most hll~ol~nt tools affecting a pro~cl's productivity. It is swlJlising therefore, that despite the conc;derable effort which the software industry has devoted to debuggers, their use is still so cumbersome. (The ill~enlo,~ believe that this results from the fact that prior art debuggers are based upon a model that was developed to support traditional character-based termin~lc-~) In view of the above, it is clear that there exists a need for an hllpro~ed debugging tool. In particular, there exists a need for a debugging tool that can abstract critical debugging il~o,lllation from increasingly complex software, display that information in a dynamic and useful graphical format and, in addition, allow the user to control program execution through operations performed directly on the graphical representation of the program.
2153~7~
.';UMl'MRY OF THE INVENTION
The pres~lll invention provides an illlyro.cd debugger having a graphical user interface. The debugger preferably operates in a client-server Co~ g e~ on~ nt A portion of the debugger, here-n~ler rerelled to as the "debugger server," ~refe.ably eYecutes on the same server colllpuler as the progl~ which is to be debugged. The debugger server rece;~es debug comm~n~lc tlanslllilled from the client colllyuler and, in cooperation with the server's operating system, eYec~ltes these co~ ndc The debugger reads certain inrol,llation, called "syrnbolic information," which is typically stored in the server colll~uler's memory or on an ~csoci~ted magnetic disk storage subsystem. The debugger server also reads program state information from that coull~uter's Illelllol~. Using the symbolic information, the debugger server derives the "call rel~tionchips" between the functions cont~ined within the program, i.e., which functions can call which other functions. The server computer then transmits this information, along with the cul-en~
program state, to the client computer.
A graphical user interface portion of the debugger is preferably resident on the client computer. This portion of the debugger receives the call relationship information and program state information led from the server. Using this inrollllalion, the user interface constructs and displays a graph of the functions col,-~,lising the program which is to be debugged. For example, the debugger could display a tree-like graphical representation of the program, wherein each function colllyli.ing the program is represented by a node on the graph and the call re!~tionships bet veen functions are illustrated by lines interconnecting the nodes. Such a graph is known as a "call treen.
-The interface of the present invention displays the call tree in several user selected folll-ats. This tree serves as a "road map" for debugging, allowing the user to easily determine the set of po~cible eYecution paths that the program may take in the future. The interface S also a~otates the call tree with addition~ rol.. ~l;Qn, such as th-e values of user-selected variables, hj~hlighting the ~iullent eYec~ltion path as detell.-ined from the function call stack, and in~li~ting, in any coll~eaient way, when a break point is set in a f~ln~ion The interf~ce also provides debugging co.. )~ lC that can be applied to the functions represented by call tree nodes. These comm~nds in(lude the ability to step program execution a function at a time, the ability to view the source code associated with a function, the ability to set a break point on a function, and the ability to "eYp~nll" and "collapse" call tree nodes, as will be discussed later in greater detail. The interface tr~nsnniLc these comm~n~ls to the server col,~puter for eYec~tion.
The user may enter debug commands into the client compuler in the traditional m~nner by typing commands on an associated keyboard. Alternatively, however, and in accordance with an important aspect of the present invention, the user may control the functioning of the debugger and enter debug comm~nds directly through the graphical interface simply by using a mouse to point and click, first directly on the node shown on the displayed call tree whereat the comm~nd is to be executed and then on a graphical symbol, such as an icon or menu item, for the desired debug comm;q~nd The ability of the present invention to graphically represent debugging inrol.llation and accept debug comm~nds through a graphical interface greatly facilitates the software debugging process. In particular, the ability of the debugger of the present invention to display a call graph with indications along the call graph showing the last function exec~ted, all prior functions eYec~lte~i and all functions which 2153~7~
could be called from the point where program eYec~ltion is suspended greatly erlh~nces the user's ability to more thoroughly and easily understand the ~ e.ll state of the l,ro~L
In relation to the analogy of the cross~ounl~ traveler descnbed S previously, the lJreSen~ invention is equivalent to providing the lla~eler with a complete road map of all highways and surface streets l~h.~ll the e~b~ation point and the ultim~te destin~tion Such a road map allows the traveler to assess the best possible means to reach a particular destin~tion. By analogy, the present invention provides the same type of road map to the programmer and allows him or her to assess the best and most efficient means to debug a program.
These and other advantages of the present invention will become more fully apparent when the following detailed descriptions of the invention are read in conjunction with the ~cco.,.p~..ying dra~
BRIEF Dl;~CRIPI'ION OF THE DRAVVING~
The invention will now be described with reference to the ?^c4~p~ rin~, d-a~ ~, wherein:
Fig. I is a block diagram of a client/server colllplltill~, system S for c~,~ g out a l)refe-led embodim~nt of the ~rese,ll invention.
Fig. 2 illustrates memory org~ni7~tion of the stack within the server colllp-~ler.
Fig. 3 is a diagram illustrating the file o~ <iltion of a complex col..p~lter program.
Fig. 4 is a flow diagram illustrating the convelsion of source code into executable code.
Fig. S is a diagram illustrating the structure of the symbolic information files created by the compiler for the program to be debugged.
Fig. 6 is a dynamic call tree created and displayed by the debugger of the present invention illustrating the possible execution paths of an order proces~in,~ program prior to debugging.
Figs. 7a and 7b are flow diagrams in accordance with a preferred embodiment of the present invention.
Fig. 8 is a dynamic call tree created and displayed by the debugger of the present invention illustrating the state of the example order processin~ program in which the fi~n~ion "Main" has called the f~ln~ion "Get Order" which subsequently called the fun~iQn "Verify Order," and wherein the "Verify Order" node has been e~r~nded to show its child nodes (functionc) when c~,..p~r~d to Fig. 6.
S FiB. 9 is a ~n~ic call tree created and di~pla~d by the de~!~eer of the present invention illustrating the same pro~ state as Fig. 8, but in addition, this figure shows that the Verify Order node was sele-cte~l and the user issued a comm~nd to display the source code co~ .ising the Verify Order function.
Fig. 10 is an "acyclic" call tree display of a program's or~ni7~tion generated by the debugger of the present invention.
Fig. Il is a "cyclic" call tree display of the olg~ t;on of the same program as illustrated in Fig. 10.
D~T~n ~n DF~ ON OF THE
PREFERRED EMBODIMENl~
The following description is of the best presently contemplqted modes of c&~l~ing out the invention. This description is made for the purpose of illusllaling the general principles of the invention and is not to be taken in a li.,liling sense.
As illustrated in Fig. 1, the debugger of the present invention is preferably decigre~ for use in a client/server co~l~uling envilo~,ent 100. The server con~ er 102 co.. ~nicates over a bus or I/O rh~nne 104 with an associated disk storage subsystem 106. The server compuler 102 in~ludes a CPU 108 and RAM 110 for storing current state infollnation about program execution. A portion of the RAM 110 is dedicated to storing the register states and local variables ~Csoci~te~
with each function of the program which is cullelllly executing on the server computer 102. This portion of RAM 110 is typically called a "program stack" or simply "the stack" 202 (Fig. 2). As illustrated in Fig.
2, the RAM locations, associated with information pertaining to each such function, are org~ni7ed in a data structure 200 known as a "frame".
The client colllpuler 112 (Fig. 1) similarly includes RAM 114, as~sociated disk memory 116, and a keyboard 118, a mouse 120 and a video display terminal (nVDl`') læ. The client CPU 123 coml,,unicates over a bus or I/O channel 124 with the disk storage subsystem 116 and via I/O ch~nnel 126 with the keyboard 118, VDT 122 and mouse 120.
Con~istent with the preferred client/server model, respective portions of the debugger software are preferably designed to operate simllltaneously on the client 112 and server 102 computers.
Coordination between the operations performed by the two portions of the debugger sohware are m~int~ined by communication over a networlc 128.
~ 2153Q75 As will be diccllcsed in greater detail below, most sofl- are pro~alus today are written in so called third gene.a~ion "high-level"
a~es which a con~ril~r tranCl~tes to m~ine inStr lctionc Programs written in third generation l~n~lages are or~ ed into S functions (also refe.l~1 to as proc~l~es or roulil~es). Fl~nGtionc are ~efine~ to ~Cl~ specific proc~-csin~ tasks. They are co..-~se~ of one or more lines of source code and may have their own local v~ bles which m~int~in state illfo~ tion that is unique to the funGtiQn Functions may call other functions to perform specific tasks. When this occurs, eYec~ltion transfers to the "called" function and will return to the "calling" function when the called function has completed the requested task.
The execNtion state of the program is m~int~ined on a "call stack," located within co~llputer memory, which records the current lS eYecution location in each function that has been called. When a filnr~ion is called, the current execNtion location in the calling function is recorded in the stack. When the called function completes, this location is removed from the stack and execution resumes at the saved location in the calling function.
As is known in the progr~mming art, program execution begins at the "Main~ routine and progresses as the Main routine calls other routines to perform various proces~ing tasks. These other called routines may in turn call yet additional routines. The execution state of a program at any particNlar time is represented by the program call stack.
As illustrated in Fig. 3, a typical program to be debugged, for example, an order processing program, may be composed of several source code files: (a) Main 300; (b) Input 302; (c) Proces~in~ 304; and (d) Output 306. Each source code file 300, 302, 304, 306 is composed of several functions 308. Each function 308 ~pically CQ~ of plural 21~307~
lines of source code 310 and, upon completing its task or upon the oc~ e~ce of a particular event, each f~ln~ion will either initiate (or ~caun) the operation of another fUnGtion 308, or return eYec~tion to the functiorl 308 which called it.
Before the order procescing ~ro~ can be run on the co~puler 102, its source code files 300, 302~ 304, 306 must be "con~riledn. Compilation ~on~elb the human-readable source code 310 into a binany code, called "object coden. Many commercially available compilers may be used in connection with the present invention. For example, a Tandem C compiler from Tandem Computers Incol~,olated of Cupertino, California may be used. This compiler generates object files in Common Object File Format ("COFFn). Many UNIX compilers also generate COFF files. The use of any particular compiler is not important to the present invention, as long as the compiler produces the .. ec~-ss~y information for use by the debugger of the present invention, as described herein.
As illustrated in Fig. 4, the compiler 410 co~ e,~ each source code file 300, 302, 304, 306 into an object code file 400, 402, 404, 406.
In addition to tr~nsl~tin~ the source code into binary coln~uter instructions, the user can also instruct the compiler 410 to include a significant amount of additional information, called "symbolic information," in each object code file 400, 402, 404, 406. The symbolic inforrnation include-s, for example, variable names, function names, variable addresses and lists of all locations within the object code file where one function calls another function. Of particular interest, with respect to the operation of the present invention, is that portion of the symbolic information from which the debugger can determine the hiel~rcl ial call relationships between the various functions 308, i.e., which f~ln~ionc 308 can call which other f~ln~ion~ 308. The symbolic i~ltul~ation typically forms a portion of each object file 400, 402, 404, 21~3 ~7S
406 stored in the con~puler's memory 110. Altcrllali~ely~ however, the symbolic inrollllation may be stored in a separate Sle located in the disk storage subsystem 106. As will be explained below, the pl~ use for the symbolic infollnation is in debugging the eYecutable plO~L
S Fig. S illustrates the structure of two typical object code files 500, 502. The Header section 504 of each file co.~ c pointers to the starting locations of the various sections of the file, for rY~mpl~, the Header section co~ u the file offset for the Fix-up Table. The Static Data section 506 of each file contains all of the co-~l~t values used by the program. The Instruction Code section 508 of each file CQ~ the actual binary coded instructions for eYecuting the program. The Function Entry Point Table 510 of each file contains a list of functions which reside in the associated file and the addresses of each such f~nction The Fix-up Tables 512 are lists of addresses within each associated file where one function 308 calls another function 308. Each Unresolved External References Table 514 contains a list of all functions 308 which are referenced within that file but are ~le-fined elsewhere.
All of the object code files are ultimately provided to a "linkerH
412 (Fig. 4). The linker 412 is a software program which combines or "links" the various object files 400, 402, 404, 406 into a program 414 that can be executed by the computer 102. An important function of the linker 412 is to read the Function Entry Point Table 510, the Fix-up Table 512 and the Unresolved References Table 514 of each object code file 400, 402, 4û4, 406. The information collectively cont~ine~l in these three tables is sufficient to enable the linker 412 to produce an executable code file 414 having the same data structure illustrated in Fig. S and all nece-ss~r references or logical connection~ 516 (Fig. 5) between the various functions originally residing in all of the object code files 400, 4û2, 404, 406 co~ ising the program.
Although the use of a compiler which generates object code files using the COFF st~nd~rd is not required by the present invention, if such a compiler is used, then the Tandem C~rnputers Incol~oraled Native Linker/Loader could be used to link the object code files.
S Alte~nali~.ely, any lillker that can process other object file fo~als could be used. Again, the use of any particular linker or any particular file format is not important to the present invention as long as the i~ollllalion ,-ecess~ to the operation of the present ill~e, debugger, as set forth herein, is provided.
During eY~cutio~ of the program, the server coll~uler 102 ...~inl~in~ il,çoll~ation in its memory 110, called "state information." As implied by the name, the state information is all inform~tion needed to ~co~ uct the c.lllenl state of the CPU 108. The state inform~tion includes the stack 202 (Fig. 2). In the usual case, this inform~tion is .,.~ i"ed as a linked 204 list of frames 200 within main memory 110.
As is known in the art, a stack pointer identif;es the function within the linked list currently being executed by the computer 102.
The debugger server reads the symbolic information stored within the server computer's memory 110 or on disk 106. As will be apparent &om the foregoing discussion, by reading the Function Entry Point tables 510, as supplemented by the linker 412 for references 516 to functions in other object code files and the Fix-up tables 512, the debugger can obtain all the information necessary to create a complete call graph for the example order processing application program (or any other program being debugged). Alternatively, in the particular instance where the debugger is operating on COFF files, where the COFF
standard does not incl~lde a Fix-up Table, then the debugger is simply pro~ -ed to synthe-si7ed Fix-up Table information by searching the m~ine instruction code for all addresses where one function calls another.
- 21!~307~
Fig. 6 illustrates such a call graph for the example order proce-scing program. Each of the twelve nodes 600 in the figure reprere,lls a particular funrtion inrlude~l within the overall PrO~L
The lines 602 connec~ the nodes 600 indicate that the left-most S fun~i~n may call the function to the right. For ~ , as set forth inthis figure, the main program f~ln~ion can initi~te calls to r~ ;O.~
(nodes) which get the order, update the d~t~b~ce, print an invoice, etc.
Each such function 600, in turn, calls sllbcidiary functions which carly out the physical steps of y~ ;n~ a visual display on the co~puler terminaL reading user input, etc.
The debugger server also reads the stack llfo~ ation from the target program's address space in the memory 110 of the server coll~ùter 102 and determines the state of the stack 202. As will be understood by those skilled in the art based upon the fcrgohlg lS ~i.cCuccion, typically, a co,l")uler has a dedicated stack pointer register or uses a general purpose register as a stack pointer. The debugger of the present invention uses the stack pointer to find the first stack frame 200. Since all stack frames are linked 204, the debugger can then easily locate the rem~ining frames. After having read the symbolic information, derived the information necessary to create a call graph as explained above and obtained the stack information, the server then transmits the call graph and stack information to the client computer 112.
The preferred embo(liment of the present invention in~ludes 2S graphical interface software resident on the client co",p,ller 112. The graphical interface software displays debugging information on the VDT
122 and receives debug comm~ntlc from the user, either via the keyboard 118 or by input from a mouse 120 operating a moveable curser or pointer 606 (Fig. 6) on the VDT 118 in a known fashion.
2ls3a7s The graphical interface software preferably incll)des as a portion thereof an off-the-shelf graphics soflware package, such as, for eA~Il~le~ Microsoft Windows, available &om Microsoft Col~olalion of Re-lmon~, W-qchineton~ or zApp Application Framework available &om Inmark Development Col~olalion of Mountvin View, Cqliforn;q Similar commercially available graphics soflware p~ages, c~pq~l~ of creating graphical d,awill~s and pe,rolming user interactions as described herein, may also be used.
Using established algolitlllns such as, for example, the "Sugiyama Algorithm", disclosed in "Methods for Visual Understqn~1in~
of Hierarchial Systems Structures", by Kow Sugiyama, Shojiro Tagawa and l~5itcuhiko Toda in IEEE Transactions On Systems, Man and ~ybernetics. Vol. SMC-11, No. 2, Februa~y, 1981, pgs. 109-125; Thesis:
Michael B. Davis, "A Layout Algorithm for A Graph Browsern, ~,~
Berkeley Engineering Library; or "A Browser for Directed Graphsn, by Lawrence W. Rowe, Michael Davis, Ely Messenger, Carl Meyer, Charles Spirakis and Alan Tuan, U.C. Berkeley Fn~ineerin~ Library.
and the call graph information transmitted from the server, the client constructs a visual rendering of the call graph on the VD,T 122. Using the stack information transmitted from the server, the client highlight5 particular portions of the rendering to indicate the execution path taken by the program.
Each of the above-identified references is incorporated herein by reference as non-essential subject matter; other known graphing algorithms may be substituted into the debugger of the present invention in place of the Sugiyama algorithm or the Davis modification of that algolilhlll.
The debugger operates according to the process steps illustrated in Figs. 7a and 7b. As seen in these figures, the ~loglalll to be debugged can be started under the control of the debugger l~r~ l 700 21~307~
or by tbe operating syctem wbich subsequently calls the deb~l~ger 702.
In either event, tbe application program is loaded into the server colll~ er's memory 110 and comes under control of the debugger server. Tbe debugger tben readc tbe symbolic inroln-~t;on 704 from tbe S server co,nputer's memory 110 or associated disk subsystem 106, derives tbe call grapb relationchips among tbe various fimCtions 706 and reads tbe frame illfol...al;on and pointer inlcl,nalion from tbe server llle,uol~
708. Tbe server then tr~ncmi~C this i~fol..~tion over tbe lletWUl~ 128 to tbe debugger client 710.
Baced upon the information transmitted from the server to the client, the graphical interface soflware residing on the client compuler 112, using the Davis enhancement to the Sugiyama algorilhlll, constructs 712, 714 and displays 716 a call graph of the program being debugged.
Since the frarne stack information is also tr~nsmitted to the client, the debugger determines and highlights the execution path of the progr~
on the call graph. Fig. 6 illustrates the call graph rendered before the debugger initiates prograrn execution. Note that, in this figure, only nMAINI~ is highlighte-l, thereby indicating that the program is ready to execute.
Utilizing the mouse 12Q the user inputs a debug cQmm~nd 718.
For example, the graphical interface software could be de-si~ed to accept comm~ntls using the "point and drag" and/or "point and click"
metho~s According to the point and drag method, a plurality of symbols representing the various debug co-lmlallds, for example, as shown in Fig. 6 at 604, may be displayed across the top of the VDT
screen 122 as a Debug Comm~nd Toolbar. The user selects an object and a comm~nd to operate on that object by manipulating the mouse 120 to move a curser or pointer 606 displayed on the VDT screen 122 until it points to the location on the call graph where the debug cotnm~nd is to be eYec~lted The user then presses the button on the 215307~
mouse, moves the mouse 120 until the pointer 606 points to the location on the c~ nd tool bar 604 displaying the icon for the desired debug co~n~ nd and releases the button. The "point and click" ~thod is similar, except that the button on the mouse 120 is pressed and r~k~l S while the poinler 606 is poi~liug to the loc~tiQn on the call graph where the co-.~ l is to be ~Yecute~l The pointer 606is then moved to the location along the toolbar 604 where the desired debug co~ d icon is located and the button on the mouse 120 is pressed and released a second time. Both methods for in~ull.ng co.. ~ 1c to general purpose co~p,llers are well known in the art.
In either event, the client then tr~ncmitC the debug comm~ncl to the debugger server, thereby c~using the order proceccin~ program to eYecute in accordance with that comm~n~ and under control of the debugger. For eY~mple, with reference to Fig. 8, if the debug comm~n~
was the entry of a break point at Verify Order 808, the program would execute up to that breakpoint. Upon re~rhing the breakpoint, the server portion of the debugger reads the frame info~ ation and transmits the current state of the program to the client. Upon receipt of this information, the client alters the display by hiehlighting the execution path followed by the program up to the break point at the Verify Order function 808. Fig. 8 illustrates the graphical user interface display at such an intermediate step in the debugging process.
Note that, by highlightinp the execution path on the displayed call graph, the invention provides the user with an easily understood graphical display showing, not only the alternative paths the prograrn could travel when the program is allowed to continue ~ ;n~" but also the execution path already traveled by the program. As previously mentioned, the values of selected variables 800 at the time the break point is encountered may also be displayed.
~15307~
If the user locates the bug based upon the displayed il~folulalion, the user then ~lrecls the error in the source program, reco~ .iles, re-links and restarts the progr~L Alternatively, if the bug is not located, then the user inputs another debug c~ d This l,loc~ es and SI~CC~ states of the pro~ are illustrated on the graphical display (along with selecte~l variables, source code and ~lis~csembled m~chine code, as desired) until all bugs are located, corrected and the p-ogr~ul performs in the proper m~nn~r.
In the course of a debugging session, a programmer will want to concentrate his or her efforts in a particular area of the p;og~ L The present invention allows the yro~ er to hide or show necec~
program detail by allowing intermediate nodes of the call tree to be "coll~rsed" (as illustrated in Fig. 6) or "expanded" (as illustrated in Fig.
~). To allow for such a control, each node which has child nodes is provided with an icon button which functions as a switch. When a node is coll~rse~l, the child function nodes will not be displayed; when eYp~nded, the child f~lnctio~ nodes are displayed. By allowing the programmer to control the level of detail displayed, the debugger is providing the capability to control the visual complexity that the user has to deal with.
Fig. 9 illustrates a display window 900 wherein the source code corresponding to the Verify Order function 908 is displayed.
Disassembled m~rlline code (not shown) could be displayed in ad-lition or as an alternative. The source code display 900 (or, alternatively, a ~lis~csembled m~chine code display) may be obtained by issuing comm~n~lc using the same "point and click" or "point and drag"
techniques disc~lssed above. In the particular case illustrated to Fig. 9, the user fir.st points and clicks on the Verify Order node 908 and then on the Source Code View menu item located under the view menu 902 along the debug ~o.~ )d tool bar. Thus, it is apparent f~om the foregoing description that the present invention provides an e ~lle~ely simple way to locate and display lines of code ~soc~?ted with a f~n~i~n and/or to issue a debug co~ zn~l such as a breakpoint, at a r..n.~;o.~, rather than having to browse the source code in search of the first line S of the target fun~ion In the call graph view, the debugged of the presenl invention has the capability to display the call graph in two modes which we call the "acyclic" (Fig. 10) and "cyclic" (Fig. 11) modes. A cycle is ~re5e~l in a call graph when there is reculsi~e function call. A rcc.~ call exists when a function calls itself or another ~lnction that is active on the program stack 202. In esse~c~ we have a loop. The t vo modes, cyclic and acyclic, have different advantages. Fig. 10 illustrates the general case of an acyclic representation of a call graph 1000 which is rendered on the VDT screen in a top-down fashion, in which the program's top-most function (main) 1002 is at the very top and subsequent child functions are indented to the right and spaced lower in the window.
The advantage of the acyclic representation is that it is visually clear because there are no lines which cross each other since the debugged replicates the function node in all the places that it is referenced. For example, if function MAIN calls functions B, I and J, and B calls functions I and M, I will be represented twice in the acyclic view. A
possible disadvantage of this representation under certain c,r~ nces is that one loses the information about how many functions call a particular f~mction In the example of Fig. 10, it is simple to see that I
gets called by MAIN and B, but it would be difficult to visually extract this info.mation from a more complex call graph.
Fig. 11 is a cyclic representation of the same call graph 1000 as is shown in Fig. 10. Here, there is no attempt at replication of nodes, but the rendering of program structure is more complex. To display a cyclical represent~tion of the call graph, the graph is laid out in a left-21~3075 to-right f~chion where the MAIN fun~ion 1002 is at the very left and e~nCion through the child nodes occurs to the right. Sinoe there is only one in~t~nce of each fUnction node, the de~ugged must show all c~-.e~:Qnc going into and out of a single represent~tion of the particular node.
For large program. with many re~ ulsi~e caLc, the cyclical represe-~t~l;on of the call graph may get very complex. This is the reacon that the present invention offers the user an option to use either mode so that the user can view the represent~tion that provides the necess3ry information in the most understandable format.
As can be seen &om the above detailed description, the present invention greatly simplifies debugging. It is particularly useful in the debugging of complex programs bec~lse the graphical nature of the display shows the user the Of g~ tion of the program in a way which prior art text-based debuggers cannot. With the present invention, the entire call graph of the program (or a selected portion of the call graph) may be displayed, thereby providing the user, in a single display, with: (a) information relating to the overall program or~ni7~tion; (b) the current state of execution of the program; (c) the execution path taken by the program to reach its .;.llrenl state; (d) alternative execution paths the program might have taken; and (e) alternative execution paths the program could take when the program is allowed to conli~ e execution. Clearly, existing text-based debuggers cannot provide such information to the user in a single, dynamic display. These five pieces of information, displayed on a single screen in a simple graphical format, combined with the ability to enter debug romm~n-l~ by acting directly on the graphical rendering of the program, greatly f~cilit~tes the debugging process.
Several preferred embodiments of the present invention have been described. Nevertheless, it will be understood that various 215307~
modifications may be made without departing from the spirit and scope of the invention. For example, debuggers according to the prese.ll invention can be run on a sinBe colll~-lter, rather than in the preferred client-server ellviro~..cn~ While execution paths may preferably be S displayed in bold or hiehli~hted video along a call graph, wLere,ll proa;~ funrtionc are represe~ted as nodes and lines cQIlnecting the nodes depict the ability of one ~1nrtio.l to call anotller filn~i~
numerous other ways of graphically conveying ~lOE5l~l o~ ;on and execution path il~ln~ation will be apparent to those of ordh~ sldll in the art based upon the present disclosure. Thus, the present invention is not limited to the preferred embodiments described herein, but may be altered in a variety of ways which will be apparent to persons slcilled in the art.
In describing the preferred embo~limentc, a number of specific technologies used to implement the embo~lim~-nts of various aspects of the invention were identified and related to more general terms in which the invention was described. However, it should be understood that such specificity is not intended to limit the scope of the rl~imed invention.
215337~
T OF APPEN~ICF~
Ap~endi~ A - Microfiche copy of source code for reading object code files and graph layout algo~ he server portion is written in Tr~n~ion Application T ~n~)age. The client portion is written ill S C~+.) ~ pendLx B - Microfiche copy of source code for a Co,lll,uler Soflware Model of the Debugging System written in the Sm~llt~
colllpu~er l~ne~ge.
Claims (20)
1. A method for debugging a computer software program on a computer system having computer memory and a graphical display output device, the method comprising the steps of:
(a) loading the software program to be debugged into the computer system, the software program including plural functions having call relationships therebetween;
(b) storing symbolic information concerning the program in the computer system's memory, including information defining the call relationships between the functions;
(c) loading debugger software onto the computer system;
(d) reading at least a portion of the symbolic information from the computer's memory with the debugger software;
(e) using the debugger software to derive, from the symbolic information, call tree relationships among the functions; and (f) using the debugger software to output a graphical display on the output device illustrating the call relationships among at least some of the plural functions.
(a) loading the software program to be debugged into the computer system, the software program including plural functions having call relationships therebetween;
(b) storing symbolic information concerning the program in the computer system's memory, including information defining the call relationships between the functions;
(c) loading debugger software onto the computer system;
(d) reading at least a portion of the symbolic information from the computer's memory with the debugger software;
(e) using the debugger software to derive, from the symbolic information, call tree relationships among the functions; and (f) using the debugger software to output a graphical display on the output device illustrating the call relationships among at least some of the plural functions.
2. The method of claim 1, wherein the graphical display includes a call tree graph.
3. The method of claim 1, wherein the graphical display includes a cyclic call tree graph.
4. The method of claim 1, wherein the graphical display includes an acyclic call tree graph.
5. The method of claim 1, further comprising the steps of:
(a) entering a debug command into the computer system;
(b) executing the software program under the control of the debugger software in a manner consistent with the debug command; and (c) outputting a visual indication on the output device, associated with the graphical display, illustrating the execution path of the program resulting from the debug command.
(a) entering a debug command into the computer system;
(b) executing the software program under the control of the debugger software in a manner consistent with the debug command; and (c) outputting a visual indication on the output device, associated with the graphical display, illustrating the execution path of the program resulting from the debug command.
6. The method of claim 5, wherein the graphical display is a call tree graph.
7. The method of claim 5, wherein the step of entering a debug command includes the step of moving a pointer to indicate the location on the graphical display wherein in the program the command is to be executed.
8. The method of claim 6, wherein the step of outputting a visual indication on the output device illus-trating the program execution path comprises the step of displaying in highlighted video those nodes on the call tree graph representing functions which have already been executed and their associated internodal connecting lines.
9. A method for debugging a program, comprising the steps of:
displaying on a computer screen a graphical representation of at least a portion of the program which is to be debugged;
highlighting those portions of the graphical representation depicting portions of the program which have already been executed; and inputting a debug command by associating a pointer on the graphical representation of the program with the location in the program where the command is to be executed.
displaying on a computer screen a graphical representation of at least a portion of the program which is to be debugged;
highlighting those portions of the graphical representation depicting portions of the program which have already been executed; and inputting a debug command by associating a pointer on the graphical representation of the program with the location in the program where the command is to be executed.
10. The method of claim 9, wherein the graphical representation is a call graph including function nodes and the debug command expands the graphical representation at the node associated with the pointer.
11. The method of claim 9, wherein the graphical representation is a call graph including function nodes and the debug command collapses the graphical representation at the node associated with the pointer.
12. The method of claim 9, further comprising the steps of;
executing the program in accordance with the debug command; and highlighting those portions of the program executed as a result of the debug command.
executing the program in accordance with the debug command; and highlighting those portions of the program executed as a result of the debug command.
13. The method of claim 9, wherein the debug command alters the display on the computer screen without causing the program being debugged to execute additional program steps.
14. A method of locating and correcting errors in the software program running in a client/server comput-ing environment including a client computer and a server computer, wherein a graphical display device is operatively coupled to the client computer, the method comprising the steps of:
(a) loading a software program onto a server computer, the software program including plural lines of code and having an inadvertent error in one of the lines;
(b) transmitting a debug command from the client computer to the server computer;
(c) executing the debug command on the server computer;
(d) transmitting, from the server computer to the client computer, information defining the execution path traveled by the program in accordance with the debug command; and (e) displaying on the graphical display device, a graphical reprsentation of at least a portion of the software program, including an indication of the execu-tion path of the program resulting from the debug command.
(a) loading a software program onto a server computer, the software program including plural lines of code and having an inadvertent error in one of the lines;
(b) transmitting a debug command from the client computer to the server computer;
(c) executing the debug command on the server computer;
(d) transmitting, from the server computer to the client computer, information defining the execution path traveled by the program in accordance with the debug command; and (e) displaying on the graphical display device, a graphical reprsentation of at least a portion of the software program, including an indication of the execu-tion path of the program resulting from the debug command.
15. The method of claim 14, wherein the display includes a call tree graph of the software programs.
16. The method of claim 14, further comprising the steps of:
prior to transmitting the debug command, entering the debug command into the client computer, wherein the step of entering the debug command includes the step of moving a pointer to indicate the location on the graphical display wherein in the program the command is to be executed.
prior to transmitting the debug command, entering the debug command into the client computer, wherein the step of entering the debug command includes the step of moving a pointer to indicate the location on the graphical display wherein in the program the command is to be executed.
17. A computer system for facilitating the debugging of a software program including multiple func-tions having call relationships, comprising:
(a) computing means for executing the program, including first memory means for storing informa-tion defining current execution status of the program;
(b) second memory means, operatively coupled to the computing means, for storing symbolic information defining the call relationships between the functions;
(c) reading means for reading at least a portion of the symbolic information and status information and for deriving therefrom the call relationships between at least some of the functions;
(d) communication means for transmitting the call relationship information; and (e) graphical display means, operatively coupled to the communication means, for receiving the call information and generating a graphical representation of program execution paths based upon the call relationship information.
(a) computing means for executing the program, including first memory means for storing informa-tion defining current execution status of the program;
(b) second memory means, operatively coupled to the computing means, for storing symbolic information defining the call relationships between the functions;
(c) reading means for reading at least a portion of the symbolic information and status information and for deriving therefrom the call relationships between at least some of the functions;
(d) communication means for transmitting the call relationship information; and (e) graphical display means, operatively coupled to the communication means, for receiving the call information and generating a graphical representation of program execution paths based upon the call relationship information.
18. The computer system of claim 17, wherein the graphical display means includes a graphical user interface for accepting user debug commands and transmitting the commands to the computing means.
19. The computer system of claim 17, wherein the graphical representation is a call tree graph.
20. The computer system of claim 18, further comprising means for generating an image of a moveable pointer on the graphical display means, wherein the user interface includes means for defining debug commands using the relative positions of the graphical representation of the program and the moveable pointer.
Applications Claiming Priority (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| US26935594A | 1994-06-30 | 1994-06-30 | |
| US08/269,355 | 1994-06-30 |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CA2153075A1 true CA2153075A1 (en) | 1995-12-31 |
Family
ID=23026900
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CA002153075A Abandoned CA2153075A1 (en) | 1994-06-30 | 1995-06-30 | Tool and method for diagnosing and correcting errors in a computer program |
Country Status (5)
| Country | Link |
|---|---|
| US (1) | US6003143A (en) |
| EP (1) | EP0690378A1 (en) |
| JP (1) | JPH0883197A (en) |
| CN (1) | CN1118473A (en) |
| CA (1) | CA2153075A1 (en) |
Families Citing this family (121)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US7266725B2 (en) | 2001-09-03 | 2007-09-04 | Pact Xpp Technologies Ag | Method for debugging reconfigurable architectures |
| JP2795244B2 (en) * | 1996-01-17 | 1998-09-10 | 日本電気株式会社 | Program debugging system |
| US6513154B1 (en) | 1996-10-21 | 2003-01-28 | John R. Porterfield | System and method for testing of computer programs in programming effort |
| DE19651075A1 (en) | 1996-12-09 | 1998-06-10 | Pact Inf Tech Gmbh | Unit for processing numerical and logical operations, for use in processors (CPU's), multi-computer systems, data flow processors (DFP's), digital signal processors (DSP's) or the like |
| DE19654595A1 (en) | 1996-12-20 | 1998-07-02 | Pact Inf Tech Gmbh | I0 and memory bus system for DFPs as well as building blocks with two- or multi-dimensional programmable cell structures |
| ATE243390T1 (en) | 1996-12-27 | 2003-07-15 | Pact Inf Tech Gmbh | METHOD FOR INDEPENDENT DYNAMIC LOADING OF DATA FLOW PROCESSORS (DFPS) AND COMPONENTS WITH TWO- OR MULTI-DIMENSIONAL PROGRAMMABLE CELL STRUCTURES (FPGAS, DPGAS, O.L.) |
| US6542998B1 (en) | 1997-02-08 | 2003-04-01 | Pact Gmbh | Method of self-synchronization of configurable elements of a programmable module |
| US6282701B1 (en) * | 1997-07-31 | 2001-08-28 | Mutek Solutions, Ltd. | System and method for monitoring and analyzing the execution of computer programs |
| JP2001515240A (en) * | 1997-09-01 | 2001-09-18 | フジツウ シーメンス コンピューターズ ゲゼルシャフト ミット ベシュレンクテル ハフツング | How to convert object code to program code |
| US8686549B2 (en) | 2001-09-03 | 2014-04-01 | Martin Vorbach | Reconfigurable elements |
| DE19861088A1 (en) | 1997-12-22 | 2000-02-10 | Pact Inf Tech Gmbh | Repairing integrated circuits by replacing subassemblies with substitutes |
| US6144954A (en) * | 1998-01-27 | 2000-11-07 | Li; Chou H. | Automatic development of computer software |
| DE69908446T2 (en) * | 1998-02-27 | 2004-05-06 | Hitachi, Ltd. | The debugging |
| US6418543B1 (en) * | 1998-07-14 | 2002-07-09 | Cisco Technology, Inc. | Apparatus and method for debugging source code |
| DE19834426A1 (en) * | 1998-07-30 | 2000-02-03 | Siemens Ag | Trigger message generation circuit arrangement |
| US6295638B1 (en) * | 1998-07-30 | 2001-09-25 | International Business Machines Corporation | Method and apparatus for loading native object code in data processing system |
| US6219804B1 (en) | 1998-08-05 | 2001-04-17 | International Business Machines Corporation | Debugging client server programs from third party workstations |
| US6202175B1 (en) | 1998-08-05 | 2001-03-13 | International Business Machines Corporation | Debuggin client server programs from third party workstations |
| US6223307B1 (en) | 1998-08-05 | 2001-04-24 | International Business Machines Corporation | Debugging client server programs from third party workstations |
| US6138157A (en) | 1998-10-12 | 2000-10-24 | Freshwater Software, Inc. | Method and apparatus for testing web sites |
| US6633912B1 (en) | 1998-10-12 | 2003-10-14 | Freshwater Software, Inc. | System, method and apparatus for providing an enterprise portal |
| US7047277B1 (en) | 1998-10-12 | 2006-05-16 | Mercury Interactive Corporation | System and computer-implemented method for creating configuration files for web transaction tests |
| US6631411B1 (en) | 1998-10-12 | 2003-10-07 | Freshwater Software, Inc. | Apparatus and method for monitoring a chain of electronic transactions |
| WO2000029950A1 (en) * | 1998-11-13 | 2000-05-25 | Channelpoint, Inc. | System, method and computer program product for dynamically generating a graphical user interface from computer program specifications |
| US6542880B2 (en) * | 1998-12-22 | 2003-04-01 | Indeliq, Inc. | System, method and article of manufacture for a goal based system utilizing a table based architecture |
| US6782374B2 (en) * | 1998-12-22 | 2004-08-24 | Accenture Global Services Gmbh | System, method and article of manufacturing for a runtime program analysis tool for a simulation engine |
| US6567933B1 (en) * | 1999-02-19 | 2003-05-20 | Texas Instruments Incorporated | Emulation suspension mode with stop mode extension |
| US7003660B2 (en) | 2000-06-13 | 2006-02-21 | Pact Xpp Technologies Ag | Pipeline configuration unit protocols and communication |
| AU5805300A (en) | 1999-06-10 | 2001-01-02 | Pact Informationstechnologie Gmbh | Sequence partitioning in cell structures |
| JP3641391B2 (en) | 1999-06-17 | 2005-04-20 | 日本電気株式会社 | Information visualization system, spatial video generation device, spatial video playback device, and information visualization method |
| US6839894B1 (en) | 1999-11-19 | 2005-01-04 | Oracle International Corporation | Method and apparatus for debugging a software program using dynamic debug patches and copy on write views |
| US6671825B1 (en) * | 1999-11-19 | 2003-12-30 | Oracle International Corporation | Method and apparatus for debugging a software program |
| US7058928B2 (en) | 1999-12-23 | 2006-06-06 | Identify Software Ltd. | System and method for conditional tracing of computer programs |
| GB2358492B (en) * | 2000-01-18 | 2004-07-07 | Mitel Semiconductor Ltd | Software debugging |
| US20020087949A1 (en) * | 2000-03-03 | 2002-07-04 | Valery Golender | System and method for software diagnostics using a combination of visual and dynamic tracing |
| WO2002010928A1 (en) * | 2000-07-28 | 2002-02-07 | Freshwater Software, Inc. | A method, system and apparatus for providing monitoring of electronic transactions |
| US8058899B2 (en) | 2000-10-06 | 2011-11-15 | Martin Vorbach | Logic cell array and bus system |
| US6871213B1 (en) | 2000-10-11 | 2005-03-22 | Kana Software, Inc. | System and method for web co-navigation with dynamic content including incorporation of business rule into web document |
| US6823518B1 (en) * | 2000-10-17 | 2004-11-23 | Microsoft Corporation | Threading and communication architecture for a graphical user interface |
| US8145742B1 (en) * | 2000-10-31 | 2012-03-27 | Red Hat, Inc. | Method of and apparatus for network administration |
| US6950868B1 (en) | 2000-10-31 | 2005-09-27 | Red Hat, Inc. | Method of and apparatus for remote monitoring |
| US8312435B2 (en) * | 2000-12-26 | 2012-11-13 | Identify Software Ltd. (IL) | System and method for conditional tracing of computer programs |
| US7844796B2 (en) | 2001-03-05 | 2010-11-30 | Martin Vorbach | Data processing device and method |
| US9037807B2 (en) | 2001-03-05 | 2015-05-19 | Pact Xpp Technologies Ag | Processor arrangement on a chip including data processing, memory, and interface elements |
| US7444531B2 (en) | 2001-03-05 | 2008-10-28 | Pact Xpp Technologies Ag | Methods and devices for treating and processing data |
| US20040205720A1 (en) * | 2001-04-30 | 2004-10-14 | Robert Hundt | Augmenting debuggers |
| US20030040887A1 (en) * | 2001-06-04 | 2003-02-27 | Shupps Eric A. | System and process for constructing and analyzing profiles for an application |
| WO2002103532A2 (en) | 2001-06-20 | 2002-12-27 | Pact Xpp Technologies Ag | Data processing method |
| US7013457B2 (en) * | 2001-07-26 | 2006-03-14 | Springsoft, Inc. | Prioritized debugging of an error space in program code |
| US7996827B2 (en) | 2001-08-16 | 2011-08-09 | Martin Vorbach | Method for the translation of programs for reconfigurable architectures |
| US7434191B2 (en) | 2001-09-03 | 2008-10-07 | Pact Xpp Technologies Ag | Router |
| US7152226B2 (en) * | 2001-09-04 | 2006-12-19 | James Pangburn | Flexible horizontal stack display and editor |
| US8686475B2 (en) | 2001-09-19 | 2014-04-01 | Pact Xpp Technologies Ag | Reconfigurable elements |
| US6996806B2 (en) * | 2001-09-21 | 2006-02-07 | International Business Machines Corporation | Graphical view of program structure during debugging session |
| EP1483682A2 (en) | 2002-01-19 | 2004-12-08 | PACT XPP Technologies AG | Reconfigurable processor |
| US8127061B2 (en) | 2002-02-18 | 2012-02-28 | Martin Vorbach | Bus systems and reconfiguration methods |
| US8914590B2 (en) | 2002-08-07 | 2014-12-16 | Pact Xpp Technologies Ag | Data processing method and device |
| US7451206B2 (en) * | 2002-05-20 | 2008-11-11 | Siemens Communications, Inc. | Send of software tracer messages via IP from several sources to be stored by a remote server |
| AU2003286131A1 (en) | 2002-08-07 | 2004-03-19 | Pact Xpp Technologies Ag | Method and device for processing data |
| US7657861B2 (en) | 2002-08-07 | 2010-02-02 | Pact Xpp Technologies Ag | Method and device for processing data |
| AU2003289844A1 (en) | 2002-09-06 | 2004-05-13 | Pact Xpp Technologies Ag | Reconfigurable sequencer structure |
| US8020148B2 (en) * | 2002-09-23 | 2011-09-13 | Telefonaktiebolaget L M Ericsson (Publ) | Bi-directional probing and testing of software |
| US7386839B1 (en) | 2002-11-06 | 2008-06-10 | Valery Golender | System and method for troubleshooting software configuration problems using application tracing |
| US20040098703A1 (en) * | 2002-11-15 | 2004-05-20 | Kondur Sankar Narayana | Integration of multiple software tools under a single site |
| US8032866B1 (en) | 2003-03-27 | 2011-10-04 | Identify Software Ltd. | System and method for troubleshooting runtime software problems using application learning |
| US7263632B2 (en) * | 2003-05-07 | 2007-08-28 | Microsoft Corporation | Programmatic computer problem diagnosis and resolution and automated reporting and updating of the same |
| JP4990623B2 (en) * | 2003-05-16 | 2012-08-01 | ピーシーエイチ インターナショナル リミテッド | Method and system for supply chain management using a visual interface |
| EP1676208A2 (en) | 2003-08-28 | 2006-07-05 | PACT XPP Technologies AG | Data processing device and method |
| US7409602B2 (en) * | 2003-11-12 | 2008-08-05 | Lsi Corporation | Methodology for debugging RTL simulations of processor based system on chip |
| US8266595B2 (en) | 2004-02-12 | 2012-09-11 | International Business Machines Corporation | Removal of asynchronous events in complex application performance analysis |
| US7496900B2 (en) * | 2004-02-12 | 2009-02-24 | International Business Machines Corporation | Method for automatic detection of build regressions |
| EP1582948B1 (en) * | 2004-03-31 | 2009-06-24 | Omron Corporation | Development aid device |
| US7827539B1 (en) | 2004-06-25 | 2010-11-02 | Identify Software Ltd. | System and method for automated tuning of program execution tracing |
| US7882492B2 (en) * | 2004-09-17 | 2011-02-01 | Oracle America, Inc. | Intelligent computer program debugger, and system and method for implementing the same |
| WO2006069491A1 (en) | 2004-12-31 | 2006-07-06 | Intel Corporation | Remote logging mechanism |
| US7496801B2 (en) * | 2005-06-27 | 2009-02-24 | Intel Corporation | Method, apparatus and system for facilitating debug for link interconnects |
| US7730246B2 (en) * | 2005-06-30 | 2010-06-01 | Intel Corporation | Opportunistic transmission of software state information within a link based computing system |
| US7472355B2 (en) * | 2005-06-30 | 2008-12-30 | International Business Machines Corporation | Computer-implemented method for managing commands for a terminal session |
| US7844854B2 (en) * | 2005-06-30 | 2010-11-30 | Intel Corporation | Opportunistic transmission of computing system state information within a link based computing system |
| US8250503B2 (en) | 2006-01-18 | 2012-08-21 | Martin Vorbach | Hardware definition method including determining whether to implement a function as hardware or software |
| US7788543B2 (en) * | 2006-03-22 | 2010-08-31 | Cisco Technology, Inc. | Methods and systems for generating and storing computer program execution trace data |
| CN100485636C (en) * | 2006-04-24 | 2009-05-06 | 华为技术有限公司 | Debugging method and device for telecommunication service development based on model drive |
| US7693257B2 (en) * | 2006-06-29 | 2010-04-06 | Accuray Incorporated | Treatment delivery optimization |
| US20080016062A1 (en) * | 2006-06-30 | 2008-01-17 | Drescher Keith A | Request-response trigger generation in link-connected computing systems |
| US7979839B2 (en) * | 2006-08-23 | 2011-07-12 | Wolf William M | Method for employing the computer in the creative act of programming |
| US8104022B2 (en) * | 2006-11-06 | 2012-01-24 | International Business Machines Corporation | Automated method for historical analysis of a memory state |
| EP2003563A1 (en) * | 2007-05-24 | 2008-12-17 | Siemens Aktiengesellschaft | Method for operating an automation device |
| US7992137B2 (en) * | 2007-07-30 | 2011-08-02 | Nvidia Corporation | Client server system for analysis and performance tuning of remote graphics devices |
| US8245212B2 (en) * | 2008-02-22 | 2012-08-14 | Microsoft Corporation | Building call tree branches and utilizing break points |
| JP2009205472A (en) * | 2008-02-28 | 2009-09-10 | Nec Corp | System, method and program for outputting log |
| US9098626B2 (en) * | 2008-04-01 | 2015-08-04 | Oracle International Corporation | Method and system for log file processing and generating a graphical user interface based thereon |
| US9823903B2 (en) * | 2008-07-18 | 2017-11-21 | Oracle International Corporation | Debugging software through visual representations mapped to computer code |
| CN101968767A (en) * | 2010-10-15 | 2011-02-09 | 北京数码大方科技有限公司 | Macroprogram-based code debugging and simulation method and device |
| US8762952B2 (en) | 2010-12-14 | 2014-06-24 | Bmc Software, Inc. | Recording method calls that led to an unforeseen problem |
| US8745598B2 (en) | 2010-12-14 | 2014-06-03 | Bmc Software, Inc. | Running injected code prior to execution of an application |
| JP5653250B2 (en) * | 2011-02-21 | 2015-01-14 | 中国電力株式会社 | Data analysis support device, data analysis support method and program |
| US8438427B2 (en) * | 2011-04-08 | 2013-05-07 | Ca, Inc. | Visualizing relationships between a transaction trace graph and a map of logical subsystems |
| CN102411534B (en) * | 2011-07-25 | 2014-12-31 | 中国科学院声学研究所 | Breakpoint debugging method and debugger |
| US9298586B2 (en) | 2011-10-11 | 2016-03-29 | Apple Inc. | Suspending and resuming a graphics application executing on a target device for debugging |
| CN102421004B (en) * | 2011-11-01 | 2014-09-03 | 深圳创维－Rgb电子有限公司 | Debugging method and device for television software system |
| CN102662821B (en) | 2012-03-22 | 2015-03-11 | 华为技术有限公司 | Method, device and system for auxiliary diagnosis of virtual machine failure |
| US8909990B2 (en) | 2012-08-04 | 2014-12-09 | Microsoft Corporation | Historical software diagnostics using lightweight process snapshots |
| US9129063B2 (en) * | 2013-05-14 | 2015-09-08 | Oracle International Corporation | Visualizing a computer program execution history |
| US20140189650A1 (en) * | 2013-05-21 | 2014-07-03 | Concurix Corporation | Setting Breakpoints Using an Interactive Graph Representing an Application |
| US9734040B2 (en) | 2013-05-21 | 2017-08-15 | Microsoft Technology Licensing, Llc | Animated highlights in a graph representing an application |
| US8990777B2 (en) | 2013-05-21 | 2015-03-24 | Concurix Corporation | Interactive graph for navigating and monitoring execution of application code |
| US9280841B2 (en) | 2013-07-24 | 2016-03-08 | Microsoft Technology Licensing, Llc | Event chain visualization of performance data |
| US9292415B2 (en) | 2013-09-04 | 2016-03-22 | Microsoft Technology Licensing, Llc | Module specific tracing in a shared module environment |
| WO2015071777A1 (en) | 2013-11-13 | 2015-05-21 | Concurix Corporation | Software component recommendation based on multiple trace runs |
| US10289411B2 (en) | 2013-11-18 | 2019-05-14 | Microsoft Technology Licensing, Llc | Diagnosing production applications |
| US9632915B2 (en) * | 2014-10-29 | 2017-04-25 | Microsoft Technology Licensing, Llc. | Historical control flow visualization in production diagnostics |
| CN107003931B (en) | 2014-12-09 | 2021-07-02 | 微福斯有限责任公司 | Decoupling test validation from test execution |
| US20160357519A1 (en) * | 2015-06-05 | 2016-12-08 | Microsoft Technology Licensing, Llc | Natural Language Engine for Coding and Debugging |
| US10496512B2 (en) * | 2016-05-11 | 2019-12-03 | Micro Focus Llc | Visualization of error flows associated with errors of different types in instances of application transactions |
| US10353802B2 (en) * | 2016-11-04 | 2019-07-16 | International Business Machines Corporation | Debugging a live streaming application |
| CN108875289B (en) * | 2017-05-08 | 2021-12-14 | 腾讯科技（深圳）有限公司 | Algorithm debugging method, client, background server and system |
| US10282274B2 (en) * | 2017-06-14 | 2019-05-07 | Microsoft Technology Licensing, Llc | Presenting differences between code entity invocations |
| GB2584038A (en) * | 2018-02-15 | 2020-11-18 | Mitsubishi Electric Corp | Software visualization device, software visualization method, and software visualization program |
| GB201808519D0 (en) | 2018-05-24 | 2018-07-11 | Undo Ltd | Debugging Systems |
| US11947966B2 (en) | 2021-10-11 | 2024-04-02 | International Business Machines Corporation | Identifying computer instructions enclosed by macros and conflicting macros at build time |
| US11481200B1 (en) | 2021-10-11 | 2022-10-25 | International Business Machines Corporation | Checking source code validity at time of code update |
Family Cites Families (7)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US4595981A (en) * | 1984-03-05 | 1986-06-17 | At&T Bell Laboratories | Method of testing interfaces between computer program modules |
| JPH02272645A (en) * | 1989-04-14 | 1990-11-07 | Hitachi Ltd | Method for supporting program debugging |
| US5124989A (en) * | 1990-01-08 | 1992-06-23 | Microsoft Corporation | Method of debugging a computer program |
| US5313616A (en) * | 1990-09-18 | 1994-05-17 | 88Open Consortium, Ltd. | Method for analyzing calls of application program by inserting monitoring routines into the executable version and redirecting calls to the monitoring routines |
| JPH04337843A (en) * | 1991-05-15 | 1992-11-25 | Hitachi Ltd | Program operation display method |
| US5410648A (en) * | 1991-08-30 | 1995-04-25 | International Business Machines Corporation | Debugging system wherein multiple code views are simultaneously managed |
| US5297150A (en) * | 1992-06-17 | 1994-03-22 | International Business Machines Corporation | Rule-based method for testing of programming segments |
-
1995
- 1995-06-28 EP EP95110074A patent/EP0690378A1/en not_active Withdrawn
- 1995-06-29 CN CN95108183A patent/CN1118473A/en active Pending
- 1995-06-30 CA CA002153075A patent/CA2153075A1/en not_active Abandoned
- 1995-06-30 JP JP7187804A patent/JPH0883197A/en active Pending
-
1997
- 1997-02-28 US US08/807,347 patent/US6003143A/en not_active Expired - Fee Related
Also Published As
| Publication number | Publication date |
|---|---|
| US6003143A (en) | 1999-12-14 |
| JPH0883197A (en) | 1996-03-26 |
| CN1118473A (en) | 1996-03-13 |
| EP0690378A1 (en) | 1996-01-03 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CA2153075A1 (en) | Tool and method for diagnosing and correcting errors in a computer program | |
| US6016474A (en) | Tool and method for diagnosing and correcting errors in a computer program | |
| US6026362A (en) | Tool and method for diagnosing and correcting errors in a computer program | |
| US10783055B2 (en) | Time travel source code debugger incorporating live coding ability | |
| US5157779A (en) | User extensible testing system | |
| JP2795244B2 (en) | Program debugging system | |
| Koskimies et al. | Automated support for modeling OO software | |
| US6151701A (en) | Method for reconstructing debugging information for a decompiled executable file | |
| US5956513A (en) | System and method for automated software build control | |
| US7272822B1 (en) | Automatically generating software tests based on metadata | |
| CA2179553C (en) | Determining dynamic properties of programs | |
| US6539390B1 (en) | Integrated development environment for aspect-oriented programming | |
| US6668370B1 (en) | Synchronous execution of object-oriented scripts and procedural code from within an interactive test facility | |
| EP0752653B1 (en) | Method and system for synchronizing the execution of events during software testing | |
| US20030159133A1 (en) | Method and system for tracing and displaying execution of nested functions | |
| EP1489512A2 (en) | Debugging breakpoints on pluggable components | |
| JPH07105044A (en) | Method and system for simulation of execution of computer program | |
| US7546585B2 (en) | Method, system and computer program product for testing computer programs | |
| Harrold et al. | Aristotle: A system for development of program analysis based tools | |
| US8719775B1 (en) | Methods and apparatus for recording and playback of an executed process | |
| Forte | Tools fair: Out of the lab, onto the shelf | |
| Pazel | DS-Viewer-interactive graphical data structure presentation facility | |
| Singhera et al. | A graphical user interface (gui) testing methodology | |
| Loveland et al. | Testing z/OS: The premier operating system for IBM's zSeries server | |
| Kent | Test automation: From record/playback to frameworks |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| FZDE | Discontinued |