1. CIS*2450 Seminar I Makefiles Debugging/Design Approaches Exception Handling Library Revision Control Designed by: Terry Moreland Updated by: Tom Crabtree

2. Makefiles Makefile Variables Makefile Variables CC = gcc CFLAGS = -Wall –std=c99 -pedantic -g LIBS = -L. -lefence Using Makefile Variables Using Makefile Variables $(CC) $(CFLAGS) …. Targets Targets : :

3. Makefiles #A sample makefile (PARTIAL) CC = gcc CFLAGS = -Wall –std=c99 -pedantic -g LIBS = -L. -lefence all: client server client: client.o common.o $(CC) client.o common.o -o client $(LIBS) $(CC) client.o common.o -o client $(LIBS) server: server.o common.o $(CC) server.o common.o -o server $(LIBS) $(CC) server.o common.o -o server $(LIBS) common.o: common.c structs.h consts.h $(CC) $(CFLAGS) -c common.c

4. Design Approaches A good design approach can make debugging a program easier A good design approach can make debugging a program easier Write small functions, if a function is getting bigger than 50 or 100 lines try looking for repetition in the function. Any repetition can be moved to a smaller functions Write small functions, if a function is getting bigger than 50 or 100 lines try looking for repetition in the function. Any repetition can be moved to a smaller functions Write small utility functions first, functions that will be used by your other functions; then test the small functions to make sure they work before moving on Write small utility functions first, functions that will be used by your other functions; then test the small functions to make sure they work before moving on

5. Design Approaches Don’t be afraid to throw away code Don’t be afraid to throw away code –If something isn’t working it can be faster to re-write than trying to fix –If your spending more than an hour trying to fix a function then think about re-writing it, or at least moving some of its functionality to smaller functions

6. Debugging Approaches Debugging is easier with small functions Debugging is easier with small functions –Nobody likes debugging a 1000 line function, and generally it’s not done because nobody writes 1000 line functions Scientific Approach Scientific Approach –There are no magic tools that work in every case, in the end you have to think about your code. –Consider where the error could be happening, and narrow down the possible choices either by commenting out code or print statements

7. Debugging Approaches Scientific Approach continued… Scientific Approach continued… –Don’t believe in magic, a printf statement is not causing your program to work; your programs behaviour is just erratic –Think and reason about what your program is doing, your brain is the best debugging tool you have

8. Debugging Tools Note: these won’t always work, don’t depend on them as they aren’t always available Note: these won’t always work, don’t depend on them as they aren’t always available Electric Fence Electric Fence –A library designed to make your program more picky about memory usage –It sets up read only memory boundaries around all allocated memory so that as soon as a boundary has been breached a seg-fault occurs –Can be used with gdb to accurately determine where a seg-fault is occuring –Usage: gcc –Wall –std=c99 –o … -lefence

9. Debugging Tools Electric Fence continued… Electric Fence continued… –Disadvantages: Speed, may not be an issue for this course, but it will be later. Electric Fence severally slows down a program (eg; With Electric Fence 5.5 Hrs, without 2.5 minutes) Speed, may not be an issue for this course, but it will be later. Electric Fence severally slows down a program (eg; With Electric Fence 5.5 Hrs, without 2.5 minutes) Not always available. It’s not always installed, and you won’t always be able to get it installed Not always available. It’s not always installed, and you won’t always be able to get it installed Doesn’t always work. Won’t work in every situation. Doesn’t always work. Won’t work in every situation.

10. Debugging Tools GDB GDB –Best used with electric fence –Usage: Compile with –g flag; eg; gcc –Wall –std=c99 –g … –Usage: gdb program-name –c core_file –GDB can analyze a core file to determine where the segfault occurred, right down to the filename and line number –Can step through a running program command by command –Can look at variable values while the program is paused –BUT… isn’t always available and doesn’t always work

11. Debugging Tools Valgrind Valgrind –Debugger/profiler package –5 tools 2 memory error detectors 2 memory error detectors –Like a combination of electric fence and gdb Thread error detector Thread error detector Cache profiler Cache profiler Heap profiler Heap profiler –Not installed by default in labs –Tutorial on course web site –http://valgrind.kde.org/ –http://www.linuxjournal.com/article/7930

12. Debugging Tools Exception Handling Library Exception Handling Library –Written by Terry Moreland –Mimics Java’s try/catch design – ANSI C Compliant –Released as open source under GPL –Can catch signals such as SIGSEGV (seg fault) –available from course website

13. Revision Control Why use revision control Why use revision control –Backups of every change you ever made to a file –If you break your code you can get an earlier copy that worked –Each version has a log entry, in theory you can find out what you changed between versions –RCS Vs CVS

14. Final Notes More detailed descriptions of the commands listed in this seminar are available online and in the linux man pages More detailed descriptions of the commands listed in this seminar are available online and in the linux man pages DO NOT DEPEND ON DEBUGGING TOOLS, they are not always there, and don’t always work DO NOT DEPEND ON DEBUGGING TOOLS, they are not always there, and don’t always work Questions ??? Comments ??? Questions ??? Comments ???