CS170 Lab 4 (kos_start) -- Starting KOS on CSIL

Here are the exact commands you may use to set up your KOS compilation environment on CSIL machines and run a program under KOS for the first time:

First, we create a directory for the new lab, copy the KOS "skeleton" files provided for you into it, and build the kos executable. 
csil$ mkdir kos_start
csil$ cd kos_start
csil$ cp /cs/class/cs170/labs/kos_start/start/* .
csil$ make clean
/bin/rm -f *.o core kos 
csil$ make
gcc34 -g  -I/cs/class/cs170/include -c exception.c
gcc34 -g  -I/cs/class/cs170/include -c kos.c
gcc34 -g  -o kos /cs/class/cs170/lib//main_lab1.o exception.o kos.o 
      /cs/class/cs170/lib//libsim.a /cs/class/cs170/lib//libkt.a 
      /cs/class/cs170/lib//libfdr.a -lnsl
Next, we copy one of the pre-built MIPS executables from test_execs (there are bunch there, but most will not work in the simple OS that you will create for this assignment). Unless you change it, kos will look for a file named a.out in its current directory, load it into memory, and execute it. Hence, we rename the program to a.out. 
csil$ cp /cs/class/cs170/test_execs/halt a.out
csil$ ./kos

KOS booting... done.


Probing console... done.
Running user code.
Machine halting!


Cleaning up...
Ticks: total 36, idle 0, system 10, user 26
Disk I/O: reads 0, writes 0
Console I/O: reads 0, writes 0
Paging: faults 0
In this case the program does nothing except stop the machine, so kos terminates immediately, printing out some execution statistics. Next, we will compile (cross-compile, actually!) a couple user programs from scratch. To keep them separate from kos code, we will place them into mips directory (which should remind us that these programs will only run on a MIPS simulator). 
csil$ mkdir mips
csil$ cp /cs/class/cs170/test_execs/src/Makefile mips
csil$ cp /cs/class/cs170/test_execs/src/good_test.c mips
csil$ cp /cs/class/cs170/test_execs/src/evil_test.c mips
csil$ make -C mips
make: Entering directory `/cs/guest/dmitrii/cs170/kos_start/mips'
/cs/class/cs170/xcomp//decstation-ultrix/bin/gcc -c -I/usr/include 
      -I/cs/class/cs170/xcomp/include -G0  evil_test.c
/cs/class/cs170/xcomp//decstation-ultrix/bin/ld -G0 -T 
      /cs/class/cs170/xcomp/support/noff.ld -N -L/cs/class/cs170/xcomp//lib 
      -o evil_test.coff /cs/class/cs170/xcomp/support/crt0.o 
      /cs/class/cs170/xcomp/support/assist.o evil_test.o 
      /cs/class/cs170/xcomp/support/libc.a 
      /cs/class/cs170/xcomp/support/libsys.a
/cs/class/cs170/xcomp/coff2noff//coff2noff evil_test.coff evil_test
numsections 3 
Loading 3 sections:
 ".text", filepos 0xd0, mempos 0x0, size 0x3090
 ".data", filepos 0x3160, mempos 0x3200, size 0x1200
 ".bss", filepos 0x0, mempos 0x4400, size 0x200
/bin/rm evil_test.coff
/cs/class/cs170/xcomp//decstation-ultrix/bin/gcc -c -I/usr/include 
      -I/cs/class/cs170/xcomp/include -G0  good_test.c
/cs/class/cs170/xcomp//decstation-ultrix/bin/ld -G0 -T 
      /cs/class/cs170/xcomp/support/noff.ld -N -L/cs/class/cs170/xcomp//lib 
      -o good_test.coff /cs/class/cs170/xcomp/support/crt0.o 
      /cs/class/cs170/xcomp/support/assist.o good_test.o 
      /cs/class/cs170/xcomp/support/libc.a 
      /cs/class/cs170/xcomp/support/libsys.a
/cs/class/cs170/xcomp/coff2noff//coff2noff good_test.coff good_test
numsections 3 
Loading 3 sections:
 ".text", filepos 0xd0, mempos 0x0, size 0x3090
 ".data", filepos 0x3160, mempos 0x3200, size 0x1200
 ".bss", filepos 0x0, mempos 0x4400, size 0x200
/bin/rm good_test.coff
make: Leaving directory `/cs/guest/dmitrii/cs170/kos_start/mips'
Neither of these programs will run in the "skeleton" kos, since it does not implement any system calls yet. So for now we will try them inside the kos that we've built for you. Our kos implements the write() system call, just as yours will if you complete the assignment. This allows good_test to run. 
csil$ cp mips/good_test a.out
csil$ /cs/class/cs170/bin/kos_start

KOS booting... done.


Probing console... done.
#0: cs170 is a great class!!
#1: cs170 is a great class!!
#2: cs170 is a great class!!
#3: cs170 is a great class!!
#4: cs170 is a great class!!
Program exited with value 5.
Machine halting!


Cleaning up...
Ticks: total 19572, idle 14500, system 10, user 5062
Disk I/O: reads 0, writes 0
Console I/O: reads 0, writes 145
Paging: faults 0
However, since our kos does not implement the sbrk() system call, which malloc() uses to request memory from the operating system, evil_test will not work in it. System call errors are silent by default, so to see them we will use the -d e debugging flag. 
csil$ cp mips/evil_test a.out
csil$ /cs/class/cs170/bin/kos_start -d e

KOS booting... done.


Probing console... done.
Unknown system call
Machine halting!


Cleaning up...
Ticks: total 50, idle 0, system 10, user 40
Disk I/O: reads 0, writes 0
Console I/O: reads 0, writes 0
Paging: faults 0
As you saw in the example execution of good_test above, the output from programs executing in kos can go directly to your terminal's standard input, to appear on your screen together with messages from kos. Likewise, your terminal's standard output is directed to the console device that can be read by processes inside kos. Alternatively, I/O of kos processes can be directed to a program executing separately from kos, called jconsole. Here is how to do it with two terminals (notice how program output appears in the second terminal, separate from the diagnostic messages produced by kos and the simulator): 
csil (TERMINAL 1)$ cp mips/good_test a.out
csil (TERMINAL 1)$ /cs/class/cs170/bin/kos_start -c 9999

KOS booting... done.


Probing console... done.
Program exited with value 5.
Machine halting!


Cleaning up...
Ticks: total 19572, idle 14500, system 10, user 5062
Disk I/O: reads 0, writes 0
Console I/O: reads 0, writes 145
Paging: faults 0

csil (TERMINAL 2)$ /cs/class/cs170/bin/jconsole 9999
KOS Console, wait...probed and started
#0: cs170 is a great class!!
#1: cs170 is a great class!!
#2: cs170 is a great class!!
#3: cs170 is a great class!!
#4: cs170 is a great class!!
Console off-line
Redirecting I/O to a jconsole process is not something you would necessarily do a lot (it is often useful to see how messages from kos and its processes are intermingled), but it can be useful, particularly while using a debugger. For instance, here we will use gdb and jconsole on your 'skeleton' kos (you can use it on the kos_start that we provide, but be sure to point gdb to the right executable, because kos_start is actually a shell script 'wrapper'): 
csil (TERMINAL 1)$ gdb kos
GNU gdb Red Hat Linux (6.5-15.fc6rh)
Copyright (C) 2006 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i386-redhat-linux-gnu"...Using host libthread_db library "/lib/libthread_db.so.1".

(gdb) break KOS
Breakpoint 1 at 0x8049a71: file kos.c, line 13.
(gdb) run -c 9999 -d e
Starting program: kos -c 9999 -d e

KOS booting... done.


Probing console... done.

Breakpoint 1, KOS () at kos.c:13
13              bzero(main_memory, MemorySize);
(gdb) continue
Continuing.
Running user code.
Unknown system call
Machine halting!


Cleaning up...
Ticks: total 1020, idle 0, system 10, user 1010
Disk I/O: reads 0, writes 0
Console I/O: reads 0, writes 0
Paging: faults 0

Program exited normally.
(gdb) quit

csil (TERMINAL 2)$ /cs/class/cs170/bin/jconsole 9999
KOS Console, wait...probed and started
#0: cs170 is a great class!!
#1: cs170 is a great class!!
#2: cs170 is a great class!!
#3: cs170 is a great class!!
#4: cs170 is a great class!!
Console off-line
So... now you are ready to go through the cook_book, which is a good way to get started.