CIS2750 Seminar 1 Created by: Terry Moreland Updated by: Tom Crabtree

1
CIS2750 Seminar 1 Created by Terry
MorelandUpdated by Tom Crabtree Anthony Koso

• Makefiles
• Debugging / Design Approaches
• Exception Handling
• Revision Control

2
Makefiles

• Determines automatically which pieces of a large
  program need to be recompiled and issues commands
  to recompile them
• Describes relationships between files
• Typically,
• source files ? object files ? executable

3
Makefiles

• Makefile Variables
• CC gcc
• CFLAGS Wall stdc99 pedantic -g
• LIBS L. lefence
• Using Makefile Variables
• (CC) (CFLAGS) .
• Targets
• lttargetgt ltdependenciesgt
• lttabgt ltcommandgt

4
Makefiles

• A sample makefile (PARTIAL)
• CC gcc
• CFLAGS -Wall stdc99 pedantic -g
• LIBS -L. -lefence
• all client server
• client client.o common.o
• (CC) client.o common.o -o client (LIBS)
• server server.o common.o
• (CC) server.o common.o -o server (LIBS)
• common.o common.c structs.h consts.h
• (CC) (CFLAGS) -c common.c

5
Design Approaches

• A good design approach can make debugging a
  program easier
• Write small functions
• If a function is bigger than 50 or 100 lines look
  for repetition in the function. Any repetition
  can be moved to 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

6
Design Approaches

• Dont be afraid to throw away code
• If something isnt working it can be faster to
  re-write than trying to fix
• If youre 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

7
Debugging Approaches

• Debugging is easier with small functions
• Nobody likes debugging a 1000 line function, and
  generally its not done because nobody writes
  1000 line functions
• 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

8
Debugging Approaches

• Scientific Approach continued
• Dont 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

9
Debugging Tools

• Note these wont always work, dont depend on
  them as they arent always available
• 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 stdc99 o -lefence

10
Debugging Tools

• 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
• Not always available. Its not always installed,
  and you wont always be able to get it installed
• Doesnt always work. Wont work in every
  situation.

11
Debugging Tools

• GDB
• Best used with electric fence
• Usage Compile with g flag eg
• gcc Wall stdc99 g
• Usage gdb program-name c core_file
• GDB can analyze a core file to determine where
  the seg-fault 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 isnt always available and doesnt always
  work

12
Debugging Tools

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

13
Debugging Tools

• Exception Handling Library
• Written by Terry Moreland
• Mimics Javas try/catch design
• ANSI C Compliant
• Released as open source under GPL
• Can catch signals such as SIGSEGV (seg fault)
• available from course website

14
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

15
Final Notes

• 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 dont always work
• Questions ??? Comments ???