Operating Systems I: Programming Tools

Download Report

Transcript Operating Systems I: Programming Tools

OS Course Assignments
•
•
•
•
•
Lecture foils are available on-line:
http://www.wright.edu/~travis.doom/courses/CEG433
WSU’s CaTS UNIX system: paladin.wright.edu
Student information is available in the directory:
– ~w001ted/pub
lab assignments are available as:
– ~w001ted/pub/ceg433/labs/labXX/labXX.worksheet.txt
All lab assignments must:
– be turned in complete and on-time (include all required files)
 labXX.makefile
 labXX.typescript (man script)
 labXX.readme
– compile without warning or error using your makefile on
paladin.wright.edu (Solaris 2).
 The compiler must be invoked with the -Wall flag
CEG 433/633 - Operating Systems I
Lab.1
Dr. T. Doom
Grading Guidelines
To earn any points, your program must compile on paladin (with -Wall flag and no warnings
or errors), with the makefile you submit (using "make -f labXX.makefile") to the target
executable file "labXX" (where XX is the two digit lab number).
Implementation/Worksheet (4 points possible):
Required: a compiling program / worksheet
4 All features implemented perfectly / all answers correct.
2 Some features implemented / some answers correct.
0 No features implemented / no answers correct.
Bugs (2 points possible):
Required: most features implemented
2 No bugs found, complete error checking done.
1 A bug found: documented in readme, demonstrated in typescript.
0 An undocumented bug found.
Documentation (3 points possible):
Required: a compiling program.
2 Extensive README: Discussion of design and implementation decisions,concepts learned,
bugs found and corrected, remaining bugs, etc. Demonstrate mastery.
1 Code documentation:
o File comment header - including your name and email at least.
o Descriptive comment blocks in code file for program and all functions, including:
purpose, arguments and flags, return values, and errors handled.
o In-code comments (preferably comment blocks for code blocks).
Excellence (1 point possible):
Required: No points deducted above.
Implementation is concise and elegant, code is easy to read (descriptively named
variables, all lines less than 80 columns, etc.), extremely well documented, all possible
errors handled and demonstrated in typescript. Generally excellent work.
CEG 433/633 - Operating Systems I
Lab.2
Dr. T. Doom
OS Programming in C/C++
•
•
•
•
C programs can easily access the services of the UNIX operating
system
System calls: routines that make operating system services
available to programmers
– creating/deleting files, allocating memory, sending signal to
processes
In C, system calls are used in the same way you use ordinary C
program modules (functions)
A variety of libraries have been developed to support
programming in C
– libraries are collections of related functions
– many libraries functions access basic OS services through
system calls
– default location is generally /usr/lib
CEG 433/633 - Operating Systems I
Lab.3
Dr. T. Doom
OS Programming in C/C++
•
•
•
Lines that begin with # are pre-processor directives
#define: used to define symbolic constants (a macro)
– provides mapping from symbolic name to replacement text (macro
expansion). Improves readability and modification.
#ifndef ALLOC
#define ALLOC(type,num) ((type *) malloc(sizeof(type) * (num)))
#endif
Header files for a library contain function prototypes and macros.
– When several macro definitions are used in different modules they
are typically collected together in a single file called a header (or
include) file (these files use the .h extention by convention).
– A function prototype is a declaration that tells the compiler what
type a function returns, how many argument a function expects,
and what the types of the arguments are. This allows the
compiler to detect and flag inconsistencies in the use of the
function
CEG 433/633 - Operating Systems I
Lab.4
Dr. T. Doom
OS Programming in C/C++
•
•
Include files are loaded by the preprocessor using the #include
directive.
– Angle brackets are used for include files located in the
“standard” location (generally /usr/include)
– #include <stdio.h>
– Double quotes are used for other locations:
– #include “/user/doom/soft/include/doomC.h”
– Another way to specify directories to be searched for header
files is to use the -I option to the C compiler
– #include “doomC.h”
– cc -I /user/doom/soft/include
If you have difficulties with a system call, check the man page
and/or the header file
– The “technical” details are available in the header files.
CEG 433/633 - Operating Systems I
Lab.5
Dr. T. Doom
OS Programming in C/C++
•
•
Each program must well organized into functional modules
– Main is the control module - execution begins and ends with
the function main
– Functions are used to make both development and
maintenance of the program more efficient
– Every function should have a clearly defined (and
documented) purpose
 Necessary conditions (pre-conditions)
 side-effects (post-conditions)
 return values
Generally speaking, a function should consist of 5 to 40 lines of
code
CEG 433/633 - Operating Systems I
Lab.6
Dr. T. Doom
Programming Tools: man, vi, xemacs
•
•
•
man
– Learn to use the man command; it is the single best tool for solving
any UNIX problem
 ex: man -k fork
 ex: man -s2 sleep
– “man man” to start
Editors
– vi: powerful and ubiquitous, steep learning curve (but worth it)
– emacs (xemacs): powerful yet cumbersome (probably worth it)
– pico: weak, small learning curve
X displays can be piped back to remote machines running an xserver:
– (remote system): setenv DISPLAY remotesystemname:0.0
– (host system):
xhost +remotesystemname
CEG 433/633 - Operating Systems I
Lab.7
Dr. T. Doom
Programming Tools
•
•
GUI - Sun WorkShop
– “workshop”: graphical environment for coding and
debugging (licensed from Sun), used to be called
“SPARCworks” in the SunOS5 days, includes:
 cc: C compiler
 sbrowser: source browser
 analyzer: performance tuner
 debugger or dbx: debugger does a good job with forks
(follow parent , child, or both)
 rsccs: source code management
 dmake: distributed make, similar to GNU make but
allows concurrency exploitation
 etc.
In my experience, workshop does not work well remotely.
CEG 433/633 - Operating Systems I
Lab.8
Dr. T. Doom
Programming Tools: gcc
•
•
C (C++) compilers
– cc (CC): SunWorkShop Compiler
– gcc (g++): GNU C Compiler, freeware, cross-platform,
ubiquitous
Compiler flags
– man gcc for details!
– -l: specify library on command line (must come after all
modules to which it applies)
– -L: specify additional directories to by searched for library
(default /usr/lib and /lib)
– -O: invoke compiler optimizer
– -o: specify executable name (default a.out)
– -W: specify warning level (implicit, return-type, unused,
comment, format, all, etc)
– ex: gcc -o lab01 -Wall lab01.c
CEG 433/633 - Operating Systems I
Lab.9
Dr. T. Doom
Programming Tools: gcc
– -c: suppress linking phase (create object files (.o) without
treating unresolved references as errors)
– ex: gcc -c doomC.c lab01.c (creates doomC.o and
lab01.o)
– ex: gcc -o lab01 doomC.o lab01.o (creates
executable lab01 by linking object files)
– -R: specify location of run-time libraries (default /usr/lib) Absolute pathnames only!
 UNIX systems use shared (dynamic) libraries - the
library modules are not included in the executable, only
the location of the *.so file. Use “ldd” to find out what
shared libraries and executable requires.
 Do not use the only style LD_LIBRARY_PATH and
LD_RUN_PATH environment variables.
 The -fPIC flag to gcc can be used to generate positionindependent code; combined with the ld -G command,
you can create your own shared libraries.
CEG 433/633 - Operating Systems I
Lab.10
Dr. T. Doom
Programming Tools: Make
•
Make: Keep a set of programs current
– C programs depend on a number of files (system header
files, user header files, C source files, object files,
executable files, etc.)
– When a changed occurs to a file that others depend on, you
MUST recompile all dependent files.
– The “make” program allows your to specify dependency
relationships to automate this process
– Make looks at at dependency lines in the specified file
 default: the files Makefile or makefile in the working
directory
 explicit: specified using the -f flag to make
CEG 433/633 - Operating Systems I
Lab.11
Dr. T. Doom
Programming Tools: Make
– Each dependency lines specifies a target file that depends
on one or more prerequisite files. If any of the files in the
dependency list has been modified since the target’s last
modification date, then the specified commands are invoked
(each line of the commands begins with a TAB)
– Syntax:
target: prerequisite-list
TAB construction-commands
lab01: doomC.o lab01.o
cc -o lab01 doomC.o lab01.o
lab01.o: lab01.h
cc - c lab01.c
doomC.o: doomC.h
cc -c doomC.c
clean:
rm -f core *.o
CEG 433/633 - Operating Systems I
Lab.12
Dr. T. Doom
Programming Tools: Make
– Implied dependencies: If you do not include a dependency
line for an object file, make assumes that it depends upon a
compiler or assembler source code file with the same name.
BEWARE: using implied dependencies requires that you
use MACROS to pass necessary flags
 If no dependency file is specified, only implied
dependencies are used
 If no target is specified, the first dependency in the file is
the default
CC=gcc
CFLAGS=-Wall
$(SRC)= doomC.c lab01.c
$(OBJ)=($SRC:.c=.o)
lab01: $(SRC) $(OBJ)
$(CC) -o lab01$CFLAGS $(OBJECTS)
#(others are implicit)
CEG 433/633 - Operating Systems I
Lab.13
Dr. T. Doom
Programming Tools: Debuggers
•
•
Debuggers
– gdb (xgdb, xxgdb - grahical): powerful, freeware, ubiquitous
 use help command at gdb prompt for: list, break, run,
set args, print, display, up, down, cont
– lint: checks programs for potential bugs and portability
problems
– truss: trace system calls and signals
Other useful commands
– Standard file commands: cp, mv, grep, diff, file, ls, mkdir, cd,
rm, chmod, ln
– Know the uses for: |, ||, &, &&, fg, bg, jobs
– Useful utilities: script, tar, compress, gzip, which, whereis,
apropos, who, w, talk, write, man, man, man
CEG 433/633 - Operating Systems I
Lab.14
Dr. T. Doom