Download presentation
Presentation is loading. Please wait.
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 !
Similar presentations
© 2024 SlidePlayer.com. Inc.
All rights reserved.