This assignment will be a bit different from most of the others this term. Instead of writing some interesting program, you are to produce a detailed written report based on experimentation with code that doesn't really do very much. Specifically, you are to create one or more test programs, poke around their insides to learn low-level details of the user-kernel interface in Solaris, and write up what you learn.
As with the previous assignment, you may work alone or in groups of two or three. This time, however, you must write your own report. You may collaborate within groups on the construction of test programs, and you may discuss issues and ideas with anyone you like, but the text you hand in must be entirely your own.
Your assignment has three sub-parts:
main
. Instead, it
starts in an initialization routine that calls main
as a
subroutine. Figure out what this initialization routine does, at the
level of individual instructions, and explain it. One possible format
for your report would be a heavily-annotated assembly language listing.
man
pages contain Tcc
(trap on integer condition codes)
instructions that cause the processor to drop into the kernel. To
implement system calls, these instructions must be combined with
conventions for passing arguments. Examine the code for some system
calls, figure out these conventions, and explain them. You might want
to start with getpid
, which takes no arguments at all, or
time
, which takes only one.
man
pages for signal (5)
, sigaction
(2)
, and signal (3c)
. Create a program that catches
a signal (timer expiration, perhaps, or ^C
from the
keyboard) and explain, at the level of individual instructions and stack
contents, how the program enters and leaves the signal handler. You may
want your program to run a tight infinite loop while waiting for the
signal, so its pc
will be in a more-or-less predictable
place when the handler is invoked.
In your attempt to figure out the low-level code in your programs, you may want to make use of several tools:
-v
and -g
switches of gcc
.
To ensure that all the code you want to inspect is actually in your
program, you will probably want to use static linking, rather
than the default dynamic linking, for the standard library. Use the
-static
option for gcc
or ld
.
man
page for dis
.
You may also want to use the x/i
command inside of
gdb
.
man
page for nm
.
You may also want to look at SPARC assembler documentation:
cs.rochester.edu
and csug.rochester.edu
domains. Note that both documents
are in PDF format, with bookmarks. If you don't see a navigation pane,
when you pull them up, click on the little double-arrow icon in the
lower left corner of your PDF plug-in's window.
Your assignment consists of the 256 assignment plus two extra parts:
-static
switch? What happens the first time you call a
function in the standard library? What happens the first time you try
to access a variable (e.g. errno
) located in a library?
man
pages for prof (1)
and
gprof (1)
. Compile a simple program with the
-p
and (separately) -gp
compiler switches.
Explain (in terms of low-level details) what happens during program
start-up and during execution to support profiling.
csh
and its
descendants, and the kernel-supported process group mechanism on
which that facility is based. Explain how the various process group
system calls are used in conjunction with signals to implement job
control.
By the date shown below, send e-mail
to cs456
containing answers to the following questions:
gcc
find the start-up code for a statically
linked program---in what file does this code reside?
gcc
.
(This is not a hard question; figure out which tool to use!)
Last Change: 30 January 2000 /