By the time you have completed this lab, you should be able to
As usual. If your regular partner is more than 5 minutes late, ask the TA to pair you with someone else for this week.
This lab's pilot should log in. You will (both) work in this account for the rest of the lab.
Create a ~/cs32/lab03 directory and make it your current directory:
mkdir ~/cs32/lab03 cd ~/cs32/lab03
Then copy eight files from the class account as follows:
cp ~cs32/labs/lab03/*.* ~/cs32/lab03
Start by reviewing key steps from a lab you probably did for CS 24 during a recent quarter. Click this link to the CS 24 lab now, and work through it to review the use of g++, make and gdb.
Did you actually perform all of the gdb-related lab steps just now? If not, go back to the gdb part of the CS 24 lab, and do those steps now. In particular, find and fix the bug described in buggy1.cpp before continuing to Step 3 of this lab.
The last thing you were told to do in the CS 24 lab was to recompile the program with the -g option. Do that now if you did not do it before. Then restart gdb:
bash-4.3$ gdb buggy1
Don't set any breakpoints. Just type "run" and try to input more than five classes. Eventually the program will crash due to a segmentation fault. Probably you know why, but this is an opportunity to learn more about gdb. After the program crashes, type "backtrace" (or just "bt") to see the sequence of calls that produced the crash. Use "list" (or "l") to list the lines near where the problem occurred (first read what backtrace told you to learn the right line number to list). You can also use "x" to examine the memory contents at a particular address.
Type your name(s) and the date in a comment at the top of buggy1.cpp, and then fix this second bug by adding a condition to the do/while loop that prevents the loop from executing after the course counter reaches 5. Recompile it and test it to make sure that execution stops cleanly after the fifth course is entered.
Is it time to switch partner roles yet?
Hopefully during your student career you are going to develop a really large program... Files often change, and having to check every line of your make file to add and delete new files can be a nightmare!
For this reason we use variables in Makefiles.
Here is a rewrite of the Makefile from the CS 24 lab:
CC = g++ # for the compiler we are going to use
CFLAGS = -c -g -Wall # options to pass to the compiler
DEPS = functions.h
LDFLAGS = # for linker/loader options like -lm
SOURCES = main.cpp functions.cpp
OBJECTS = $(SOURCES:.cpp=.o) # means copy .cpp names to .o names ;-)
EXECUTABLE = hello # for the executable program's name
all: $(SOURCES) $(EXECUTABLE)
$(EXECUTABLE) : $(OBJECTS)
$(CC) $(LDFLAGS) $(OBJECTS) -o $@
main.o : main.cpp functions.h
$(CC) $(CFLAGS) main.cpp
functions.o : functions.cpp functions.h
$(CC) $(CFLAGS) functions.cpp
clean:
rm $(EXECUTABLE) $(OBJECTS)
Ok much better, but it can be generalized even more in cases where there are more than just two files that have to be compiled. The two targets, main.o and functions.o can both be replaced by the following target/command combination:
%.o: %.cpp $(DEPS)
$(CC) $(CFLAGS) *.cpp
Try to figure out what that target/command combination accomplishes.
Now it is time for you to create a Makefile. See the three files, buggy2.cpp, bankaccount.h and bankaccount.cpp. Both bankaccount.cpp and buggy2.cpp include bankaccount.h, and each of them should be separately compiled (with debugging information included) to bankaccount.o and buggy2.o. Then they should be linked to create an executable named buggy2. Write the Makefile to accomplish those tasks now. Use variables like the example above, and include a "clean" target like that example too. Add your name(s) and the date in a comment at the top of your Makefile (comments are denoted by the "#" character).
Test your Makefile, first by typing just "make" to verify there are no compilation or linking errors, then by typing "make clean" to verify the executable and .o files are successfully removed.
Edit your Makefile as necessary to correct any errors. Be sure, for example, that commands are preceded by a tab character, not a bunch of spaces!
Use make to compile/link and buggy2.cpp and bankaccount.cpp again (if your Makefile did not compile with the -g option, then fix that first).
Start gdb on buggy2, and then type run:
-bash-4.3$ gdb buggy2 GNU gdb (GDB) ... (gdb) run
Type "bt" after the crash to find out where the problem occurred, and then use "list" and the line number to see the lines around that problem.
Type "quit" to exit gdb. Edit the program to eliminate the problem, and type your name(s) and the date at the top of the file you edit. Use make to recompile. Then run it to test. Correct and complete output should match the following:
-bash-4.3$ ./buggy2 Start of Test: account1 initial statement: Account balance $123.99 Interest rate 3.00% account1 with new setup: Account balance $100.00 Interest rate 5.00% account1 after update: Account balance $105.00 Interest rate 5.00% account2: Account balance $105.00 Interest rate 5.00%
By the way, here is a gdb reference card that shows many more gdb commands you can use in the future.
You MUST have both your name and your partner's name in buggy1.cpp, Makefile, and whatever file(s) you edited from the trio buggy2.cpp, bankaccount.h and bankaccount.cpp in order to receive credit. Remember that the original pilot needs to do this step, since that is whose account you have been using in the lab.
Bring up a terminal window on CSIL, and cd into the original pilot's ~/cs32/lab03 directory. Then type the following to turn in the file:
turnin lab03@cs32 buggy1.cpp Makefile buggy2.cpp bankaccount.h bankaccount.cpp
Verify that all five files are being turned in successfully.
Each pair of students must accomplish the following to earn full credit [50 points] for this lab:
This lab is due by 11:59 pm tonight.
Prepared by Michael Costanzo, using some materials from Stratos Dimopoulos (former TA).