CS560 TA Web PAge

Spring 2007 TA: Mitch Horton

We put this page together to provide some additional lab tips and help keep the class informed about lab policies, submissions, and other administrivia. Check back often.

Links

• Dr. Beck's CS560 (for Spring 2007)
• CS560 Labs
• Lecture Notes
• CS560 Cross Compiling for JOS
• Dr. Plank's CS360
• CS560 Frequently Asked Questions
• CS560 General Style Deductions

First Things First

If one thing is essential to success in this class, it's reading the documentation. The man pages are often your best reference - whether you are implementing a shell or writing your own system calls. Learn to use them. Some utilities don't have extensive man pages, but instead use the info system. You can see the gcc info page by typing info gcc , for instance.

Lots of information on the GNU utilities like gcc, gdb and make can be found at the GNU documentation site at www.gnu.org/manual.

Submitting Labs

1. Change to the directory containing the lab files.
2. Remove all unnecessary files (.o files, test files, test code).
3. Run the /home/cs560/560submit script.
4. Enter the number of the lab you're submitting at the prompt.
5. Your lab has now been submitted. You should recieve a confirmation when your TA unpacks the lab. If you do not recieve this confirmation within a few days, email your TA.

UNIX> pwd
/home/jones/cs560/lab1
UNIX> ls
jshell*     jshell.c    jshell.o     makefile
UNIX> rm jshell.o jshell 
UNIX> ls
jshell.c   makefile
UNIX> ~cs560/560submit
<< Which Lab ??  (1,2,3,4,5,6,7,8)  >>
1



Tue Aug 29 16:51:50 EDT 2000
Lab1 mailed to cs560

• NOTE
• Submitting a set of files that will not compile is equivalent to sending a non-working lab.
• Several of Dr. Plank's labs include source files that should not be touched. Either submit copies of those files or symbolic links to those files. Both methods work.
• Make sure that you test out the files you are submitting before running the submission script.
• Also, make sure that you are submitting only source files, a makefile, and a README, if necessary. Deductions will be taken for not following these directives.

Lab Grading Hints

For maximum credit, your lab should (at least) ...

• be commented generously.
• be easy to read and understand.
• output messages that are easy to understand.
• always exit under program control with no OS panics, segmentation violations, I/O errors, etc.
• always initialize variables before use.
• always check function and system call return codes.

Late Labs

• One lab may be turned in up to seven days past the due date.
• The final lab must be turned in on time to receive any credit.
• Otherwise, any labs turned in late will be receive zero credit.

Compiling and Linking in CS560

You will be doing a lot of code compilation in 560. We assume everyone knows how to use the GNU compiler, gcc. Don't use the Sun compiler, cc.

A couple of handy switches for gcc:

• -g: includes symbol information in the executable. This is essential for debugging; without it, gdb is clueless.
• -Wall: Under this option, the compiler will be very verbose with its warnings about questionable constructs in your program. It's always good to compile with -Wall just to catch silly mistakes.

In most labs you will be using Dr. Plank's Dllist, Jval, and JRB-tree libraries. We have provided static libraries for you to link against under ~cs560/lib. Browse around there and see what you can find. You'll notice that the libraries are organized by architecture; we have both Solaris and Linux libs.

make

560 will be grim without make. Most of you are doubtless familiar with it, but if you aren't, read the info page and get cozy with this wonderful utility. We prefer the use of GNU make, which is in /usr/local/bin/make on the Linux boxes. Beware - there are other makes on our system and they don't all share syntax.

Debug tools

You will be doing lots of debugging. GDB is always a good place to start. If you don't already know how, check out the docs and play with stepping through a running program. One feature of GDB which will be particularly handy is its ability to connect to an already running process.

Purify - this is a commercial package which finds all kinds of code problems, from memory leaks to bounds overruns. It is VERY GOOD STUFF and is simple to use (it even has a X interface).

dumpRam - We're providing a simple function for pretty-printing a portion of main_memory (part of the JOS labs). Its there for your use.If you think it causes problems with your code, don't use it.

• Source Code Commenting
  Source Code for each lab needs to be commented. The cs560 TAs are only requiring that you use block level commenting. Comments should be used to give an overview of the code and provide additional information that is not readily understandable from the code itself. It is not necessary that you comment every line in your code. When documenting a program, say only what needs to be said without leaving important things out. We should be able to read only your comments and get a general idea of what your code is doing and how it is doing it.
• Source Header
  All source files (*.c and *.h) should include a main header at the beginning of the file. Minimally, this header should include your name and a brief description of what the file contains.
• Function Headers
  All functions need to have a header that includes at least the following information:
  • Function name
  • A brief description of what the function is doing
  • Inputs into the function
  • Outputs from the function
  • Return values and the conditions under which they will be returned
  You are free and encouraged to include more information in your function headers, but the above five pieces of information need to be present. The goal here is to convey to the TA's that you know what your code is doing. As long as you feel that you are doing so, you should be ok.
• Modularity / Function Decomposition
  Most of your cs560 labs are going to require more lines of code than in previous courses and it is important to break your code into functions. A function should perform a specific task or a collection of small highly related tasks. Do not stuff all your code in the main function. Source code is easier to read and debug if it is divided into multiple functions.
• Error Checking
  The following need to be error checked in all labs:
  • All command line arguments (did the user enter what you expected for each argument)
  • Number of command line arguments (are there too many or not enough arguments)
  • Return values of system calls
  If an error occurred make sure to output a meaningful error message to either stdout or stderror and have your program exit gracefully.
• Global Variables
  Do not use global variables in the first three labs unless given permission from the instructor or one of the TAs. Global variables are required for the JOS labs to function correctly.
• Final Notes
  Some administrivia that does not fit elsewhere:
  • In the JOS labs, you will be adding code to some existing code files. We expect you to place appropriate headers for both the source file and the functions.
  • Make sure that you have named your executable as required in the lab writeup. For example, the JOS labs require that you build an executable named jos.
  • Put your name in your source code. Yes, it is that important!
  • If in doubt, ask a TA. These rules are meant to help both you and us.
  If an error occurred make sure to output a meaningful error message to either stdout or stderror and have your program exit gracefully.