/ | -------------- / | \ bin home usr ... | --------------- / | \ ... you ... | ---------------------- / | \ ... cs31 ... | ------------------------- / | \ inclass labs weeklylab / / / \ 01 ... 01 ... week01 week02 ... / files you copy overIf you have not already done so, first run update31 to create the cs31/inclass/01 subdirectory and copy over files from lecture this week and files refered to in the "Intro to C for 31 Students" document off week 1 of the class schedule:
update31Next, create the cs31/weeklylab/week01 directory structure and copy over some files into your week01 directory:
cd cd cs31 mkdir weeklylab cd weeklylab mkdir week01 cd week01 pwd cp ~newhall/public/cs31/week01/* . ls Makefile arrays.c structs.c testprog.c types_scanf.c
Now, let's try it out on one of the files you copied over (we will use the -g and -o outfile options to gcc):
gcc -g -o testprog testprog.c ./testprogWith the code you copied over is a Makefile. In this file are rules for compiling executables from the .c source files that are executed by typing in the make command. make is very convinent way to compile without having to type in a long gcc command every time, you just need to type make:
make # this will compile all files as specified by the all: rule make clean # this removes all files generated by make (the can be rebuilt)
To use the debugger, you usually want to compile your C program with the -g flag to add debugging information to the a.out file (this allows gdb to map machine code to C program code that the programmer understands).
$ gcc -g -o testprog testprog.cActually, the makefile already has this rule for us, so let's just run make Next, we will run the executable file inside the gdb debugger:
$ gdb ./testprogThe first thing we get is the gdb prompt (our program has not yet started). Typically we will set a break point at main. A breakpoint tells gdb to grab control at a certain point in the execution, in this case right before the first instruction in main is executed:
(gdb) break mainNext, we will enter the run command at the gdb prompt to tell gdb to start running our program:
(gdb) runThe run command will start your program running, and gdb will only gain control again when a breakpoint is hit.
There are a few other main gdb commands we will learn today, the first is next (or just n for next), which tells gdb to execute the next instruction and then grab control again:
(gdb) next # this will execute the instruction x = 10The list command lists the C source code around the point where we are in the execution:
(gdb) listlist with a line number lists the source code around that line:
(gdb) list 30cont tells gdb to let the program continue running. Since we have no more breakpoints it will run until termination.
Now lets add a breakpoint in the function mystery, and rerun the program:
(gdb) break mysteryLets set a breakpoint at line 20, right before the call to mystery, then type cont to continue execution from breakpoint in main :
(gdb) break 20 (gdb) cont (gdb) listWe can use the print command to print out expressions in the program, so let's print out the values of the arguments passed to mystery, and type cont to run until the next break point is hit:
(gdb) print a # print out the value of the variable a (gdb) print (a - 4) # print out the value of the expression (a - 4) (gdb) list
The where or bt command list the call stack:
(gdb) whereLets step through some of the mystery function's execution, and print out some of its parameters and locals.
When you are all done using gdb, type the command quit.
Now let's just try running commandargs in gdb, to see how to run this program:
gdb ./commandargsFor programs that take command line arguments, list the arguments after the run command:
(gdb) break main (gdb) run 6 4 helloExamine some run-time state of this program, and then quit gdb
We will talk more about C and gdb over the course of the semester.
Off my "Unix and CS Info Pages and Links" page are some C programming and
gdb references that will be useful this semester: