Download Using GDB: A Debugger for Computer Science Students and more Study notes Algorithms and Programming in PDF only on Docsity! UNIVERSITY OF CALIFORNIA Department of Electrical Engineering and Computer Sciences Computer Science Division CS61B P. N. Hil nger Spring 1995 Simple Use of GDB A debugger is a program that runs other programs, allowing its user to exercise some degree of control over these programs, and to examine them when things go amiss. In this course, we will be using GDB, the GNU debugger1. GDB is dauntingly chock-full of useful features, but for our purposes, a small set of its features will suce. This document describes them. Relatively complete documentation of gdb is available on-line in Emacs (use C-h i and select the \GDB" menu option). There is also a paper reference manual available at the ASUC bookstore, The GDB Reference Manual by the Free Software Foundation, which contains the same information as is on-line. Basic functions of a debugger When you are executing a program containing errors that manifest themselves during execu- tion, there are several things you might want to do or know. What statement or expression was the program executing at the time of a fatal error? If a fatal error occurs while executing a function, what line of the program contains the call to that function? What are the values of program variables (including parameters) at a particular point during execution of the program? What is the result of evaluating a particular expression at some point in the program? What is the sequence of statements actually executed in a program? 1The recursive acronym GNU means \GNU's Not Unix" and refers to a larger project to provide free software tools. 27 28 P. N. Hil nger These functions require that the user of a debugger be able to examine program data, to obtain a traceback|a list of function calls that are currently executing sorted by who called whom|, to set breakpoints where execution of the program is suspended to allow its data to be examined, and to step through the statements of a program to see what actually happens. GDB provides all these functions. It is a symbolic or source-level debugger, creating the ction that you are executing the C++ statements in your source program rather than the machine code they have actually been translated into. Starting GDB In this course, we use a system that compiles (translates) C++ programs into executable les containing machine code. This process generally loses information about the original C++ statements that were translated. A single C++ statement usually translates to several machine statements, and most local variable names are simply eliminated. Information about actual variable names and about the original C++ statements in your source program is unnecessary for simply executing your program. Therefore, for a source-level debugger to work properly, the compiler must put back this super uous information (super uous, that is, for execution). A standard way to do so is to add it into the information normally used by the linker in the executable le. To indicate to our compiler (gcc) that you intend to debug your program, and therefore need this extra information, add the -g switch during both compilation and linking. For example, if your program comprises the two les main.C and utils.C, you might compile with gcc -c -g -Wall main.C gcc -c -g -Wall utils.C gcc -g -o myprog main.o utils.o or all in one step with gcc -g -Wall -o myprog main.o utils.o Both of the sample command sequences above produce an executable program myprog. To run this under control of gdb, you can type gdb myprog in a shell. You will be rewarded with the GDB command prompt: (gdb) This provides a clumsy but e ective text interface to the debugger. I don't actually recom- mend that you do this; it's much better to use the Emacs facilities described below. However, the text interface will do for describing the commands.