1. Plab – Tirgul 3 Makefiles, Libraries, Debugging and Common Bugs

2. Compilation & linkage.h read.h.c read.c.c main.c.c list.c.h list.h prog1 Linkage: g++ read.o main.o list.o –o prog1.o main.o.o list.o.o read.o Compilation: g++ -c read.c main.c list.c

3. Compilation & linkage.h read.h.c read.c.c main.c.c list.c.h list.h prog1.o main.o.o list.o.o read.o If only one file is modified, will we have to recompile all over again? No. The Makefile uses the dependencies graph

4. Aim: Build only out-of-date files (use timestamps) Makefile contains: –List of dependecies (no cycles) –“Recovery” scenario when any file is modified main.o: main.c list.h read.h g++ -c main.c In words, if any of the files {main.c, list.h, read.h} was modified after main.o, the command “g++ -c main.c” will be performed Makefile Note, the tab here is essential!

5. Compilation & linkage.h read.h.c read.c.c main.c.c list.c.h list.h prog1.o main.o.o list.o.o read.o If read.h is modified, what should be done? We have to recreate only a subset of the files!

6. Compilation & linkage.h read.h.c read.c.c main.c.c list.c.h list.h prog1.o main.o.o list.o.o read.o Makefile example: prog1: read.o main.o list.o g++ main.o read.o list.o –o prog1 main.o: main.c read.h list.h g++ -c main.c read.o: read.c read.h g++ -c read.c list.o: list.c list.h g++ -c list.c Running make, e.g: make prog1 make main.o

7. Makefiles: macros Macros are similar to variables –Upper case by convention Example: OBJECTS = read.o list.o main.o prog1: ${OBJECTS} g++ ${OBJECTS} -o prog1

8. Makefiles: Explicit/implicit rules We saw “explicit rules” so far, e.g: list.o: list.c list.h g++ -c list.c Implicit rules (many kinds): –Example, creation by suffices. Create “.o” files from “.c” files.c.o: $*.c g++ -c –o $@ $< $* - the match without the suffix (e.g. list) $@ - file for which the match was made (e.g. list.o) $< - the matched dependency (e.g. list.c)

9. Makefiles: Explicit/implicit rules One more example for implicit rule:.java.class: $*.java javac $< Result: For every “.java” file that was modified, a new “.class” file will be created. When no explicit rule defined, an implicit rule will be used. –not always sufficient (e.g. doesn’t check.h files update)

10. Libraries

11. Library is a collection of functions, written and compiled by someone else, that you may want to use Examples: –C’s standard libraries –Math library –Graphic libraries Libraries may be composed of many different object files

12. Libraries 2 kinds of libraries: Static libraries: –linked with your executable at compilation time –standard unix suffix:.a Shared libraries: –loaded by the executable at run-time –standard unix suffix:.so

13. Static libraries Using the static library libdata.a: g++ -o prog object1.o object2.o –ldata Creating the library data.a (2 commands): ar rcu libdata.a data.o stack.o list.o ranlib libdata.a ar is like tar – archive of object files ranlib builds a symbol table for the library –to be used by the linker

14. static vs. shared Static libraries pros: Independent of the presence/location of the libraries Less linking overhead on run-time Shared libraries pros: Smaller executables No need to re-compile executable when libraries are changed The same executable can run with different libraries Dynamic Library Loading (dll) possible

15. Libraries in makefile libdata.a:${LIBOBJECTS} ar rcu libdata.a ${LIBOBJECTS} ranlib libdata.a OBJECTS = foo.o bar.o CC = g++ prog: ${OBJECTS} libdata.a ${CC} ${OBJECTS} –ldata –o prog

16. Debugging 101 1.“Define” the bug --- reproduce it 2.Divide & Conquer 3.Use tools: debugger & more 4.Don’t panic --- think!

17. Define the bug Spend the time to find out What is wrong? Minimal settings that lead to the error? Reproduce the wrong behavior! Preferably on a small example

18. Divide & Conquer Consider possible points of failure –check each one of them separately

19. Use Debugger Debugger Allow to monitor run time behavior Check where the program crashes Put breakpoints on specific events Trace execution of the program

20. Debugger Debugger can save a lot of time Find why the program crash Understand the context (call tree, value of variables, etc.) But… Don’t be trapped into using debuggers all the time

21. Other tools Intermediate printouts self-checking code asserts Memory allocation & leaks (Lecture)

22. Don’t Panic There a sensible explanation to the bug –Always! –Don’t rush to blame the compiler/OS –Don’t attribute bugs to mysterious forces Do not try random changes to see if they resolve the program –This will only introduce more bugs!

23. Some very common bugs (memory/pointers related)

24. bug 1 (1)struct Student { (2)int id; (3)char * name; (4)}; (5)Student * stud = (Student *) malloc( sizeof(Student) ); (6)stud->id = 123456; (7)stud->name = (char *) malloc(100*sizeof(char)); … (8)if (stud != NULL) { free(stud); } Memory leak!!! “name” is not free

25. bug 2 1)void myFunc() { 2) int * x = randomNum(); 3) int result = *x; //unexpected ! 4) *x = 17; //accessing unallocated space! 5)} 6) 7) int * randomNum() { 8) int j= srand( time(0) ); 9) return &j; 10) } u Never return a pointer of a stack-variable !

26. bug 3 1)void myFunc(char * input) { 2) char * name = NULL; 3) if (input != NULL ) { 4) name = (char*)malloc(MAX_SIZE); 5) strcpy(name,input); 6) } 7) … 8) free( name ); 9)} u Always use: if (output != NULL ) { free(output); }

27. bug 4 1)void myFunc(char * input) { 2) char * name; 3) if (input != NULL ) { 4) name = (char*)malloc(MAX_SIZE); 5) strcpy(output,input); 6) } 7) … 8) if ( name != NULL ) { 9) free( name ); 10) } 11)} u Always initialize pointers to NULL !