The objective of this introductory lab is to familiarize you with the process of compiling and running XINU, the tools involved, and the run-time environment and segment layout.<\/p>\n
XINU is a small Unix-like operating system originally developed by Douglas Comer for instructional purposes at Purdue University. It is small enough so that we can understand it entirely within one semester. As part of lab assignment, we will re-implement or improve some apsects of XINU.<\/p>\n
Step 1: Setting environment variables for lab assignments:<\/p>\n
Get access to a customized VCL image — XINU+QEMU (CSC501) <\/i>— through the VCL <\/a>facility<\/p>\n Step 2: Untar the XINU source files as follows:<\/p>\n 2. Untar the XINU source by typing the following:<\/p>\n The csc501-lab0.tgz <\/strong>file is available is available on moodle<\/a>.<\/p>\n In your home directory, you will now have a directory named csc501-lab0. The subdirectories under this directory contain source code, header files, etc, for XINU. NOTE: the tar file name may be different from the above depending on the lab you are working on. Please refer to the lab handouts for the location of the tar file for the current lab.<\/p>\n Step 3: Building XINU<\/p>\n To compile the XINU kernel which will be downloaded and run on the backend machines, run “make” in the compile directory as follows:<\/p>\n e entirely written in x86 assembly. You should not use inline assembly, (i.e., do not use asm(???)). To investigate the assembly code generated by the compiler, you can use the tool objdump -d <___.o> to disassemble an object file. The object files reside in the \/compiledirectory within the main Xinu directory. You can also see some of the *.S files in the \/sys directory for reference.<\/p>\n If you get a permission denied issue, please go to the config<\/strong> directory and change permission of config file<\/strong>, and then compile using the previous commands.<\/p>\n Step 4: Running and debugging XINU<\/p>\n The XINU image runs on the QEMU emulator machines. To boot up the image, type:<\/p>\n XINU should start running and print a message “Hello World, Xinu lives.”Typing (“control-a”, then “c”) will always bring you to ‘(qemu)’ prompt. From there, you can quit by typing ‘q<\/b>‘<\/p>\n To debug XINU, run the image in the debug mode by:<\/p>\n Then execute GDB in another ssh session:<\/p>\n In the (gdb) console, connect to the remote server by:<\/p>\n You can use many debugging features provided by GDB, e.g., adding a break point at the main function:<\/p>\n To run to the next breakpoint, type:<\/p>\n The detailed document for GDB can be found here<\/a><\/p>\n Note: The Intel document is hundreds of pages long and there is no need to print it. Please do not print it!<\/p>\n You will be using the csc501-lab0.tgz<\/tt> you have downloaded and compiled by following the lab setup guide. And you are asked to write several XINU functions that perform the following tasks:<\/p>\n 1. long zfunction(long param)<\/tt><\/b><\/p>\n Clear from the 10th to 18th bits (counting left to right, the left most bit is the 0th bit), shift the parameter param by 4 bits to the left, and then fill the right most bits with 0. For example, the input parameter 0xaabbccdd<\/tt> should generate a return value of 0xa800cdd0<\/tt>. You can assume that the size of long is 4 bytes. The code for this function should be entirely written in x86 assembly. You should not use inline assembly, (i.e., do not use asm(???)<\/tt>). To investigate the assembly code generated by the compiler, you can use the tool objdump -d <___.o><\/tt> to disassemble an object file. The object files reside in the \/compile <\/tt>directory within the main Xinu directory. You can also see some of the *.S files in the \/sys<\/tt> directory for reference.<\/p>\n (Tips: please check out the 2nd and the 3rd readings above before doing this question.)<\/p>\n 2. void printsegaddress()<\/tt><\/b><\/p>\n Print the addresses indicating the end of the text, data, and BSS segments of the Xinu OS. Also print the 4-byte contents (in hexadecimal) preceding and after those addresses. This function can be written in C.<\/p>\n 3. void printtos()<\/tt><\/b><\/p>\n Print the address of the top of the run-time stack for whichever process you are currently in, right before and right after you get into the printtos()<\/tt> function call. In addition, print the contents of upto four stack locations below the top of the stack (the four or fewer items that have been the most recently pushed, if any). Remember that stack elements are 32 bits wide, and be careful to perform pointer arithmetic correctly. Also note that there are local variables and arguments on the stack, among other things. See the hints given for #4 below, especially on stacktrace.c and proc.h. Your function can be written entirely in C, or you can use in-line assembly if you prefer.<\/p>\n 4. void printprocstks(int priority)<\/tt><\/b><\/p>\n For each existing process with larger priority than the parameter, print the stack base, stack size, stacklimit, and stack pointer. Also, for each process, include the process name, the process id and the process priority.<\/p>\n To help you do this, please look into proc.h<\/tt> in the h\/<\/tt> directory. Note the proctab[]<\/tt> array that holds all processes. Also, note that the pesp member of the pentry structure holds the saved stack pointer. Therefore, the currently executing process has a stack pointer that is different from the value of this variable. In order to help you get the stack pointer of the currently executing process, carefully study the stacktrace.c<\/tt> file in the sys\/<\/tt> directory. The register %esp<\/tt> holds the current stack pointer. You can use in-line assembly(i.e., asm(\"...\")<\/tt>) to do this part.<\/p>\n 5. void printsyscallsummary()<\/tt><\/b><\/p>\n Print the summary of the system calls which have been invoked for each process. This task is loosely based on the functionality of LTTng <\/a>. There are 43 system calls declared. Please look into kernel.h<\/tt> in the h\/<\/tt> directory to see all declared system calls. However, only 27 system calls are implemented in this XINU version. The implementation of these 27 system calls are in the sys\/<\/tt> directory. You are asked to print the frequency (how many times each system call type is invoked) and the average execution time (how long it takes to execute each system call type in average) of these 27 system calls for each process. In order to do this, you will need to modify the implementation of these 27 types of system calls to trace them whenever they are invoked. To measure the time, XINU provides a global variable named ctr1000<\/tt> to track the time (in milliseconds) passed by since the system starts. Please look into sys\/clkinit.c<\/tt> and sys\/clkint.S<\/tt> to see the details. Implement this lab as a set of functions that can be called from main()<\/tt>. Each function should reside in a separate file in the sys directory, and should be incorporated into the Makefile. The files should be named after the functions they are implementing with C files having the .c extension and the assembly files having the .S extension. For example, the file that will hold void printsegaddress()<\/tt> should be named printsegaddress.c<\/tt>; and the file that will hold long zfunction(long param)<\/tt> should be named zfunction.S<\/tt>. You should put syscallsummary_start, syscallsummary_stop <\/tt>functions in the same file as printsyscallsummary <\/tt>function and name it as printsyscallsummary.c <\/tt>. If you require a header file, please name it lab0.h<\/tt>. Note: as you create new files, you may need to update the Makefile<\/tt> (located in the compile\/<\/tt>directory) to configure it to compile your files correctly. Just look at what is done for the existing files (e.g., main.c<\/tt>) to see what you have to do.<\/p>\n Write your answers to the following questions in a file named Lab0Answers.txt (in simple text).<\/p>\n Please place this file in the sys\/ directory and turn it in, along with the above programming assignment.<\/p>\n Electronic turn-in instructions:<\/p>\n You can write code in main.c to test your procedures, but please note that when we test your programs we will replace the main.c<\/tt> file! Therefore, do not put any functionality in the main.c<\/tt> file.<\/p>\n Also, ALL debugging output MUST <\/b>be turned off before you submit your code.<\/p>\n\n
cd<\/b><\/pre>\n
tar xzvf csc501-lab0.tgz<\/b><\/pre>\n
cd csc501-lab0\/compile\nmake depend<\/b><\/pre>\n
\nmake\n<\/b>This creates an OS image called 'xinu.elf'.<\/pre>\n
chmod 755 config<\/b><\/pre>\n
make run<\/b><\/pre>\n
make debug<\/b><\/pre>\n
gdb xinu.elf<\/b><\/pre>\n
target remote localhost:1234<\/b><\/pre>\n
b main<\/b><\/pre>\n
c<\/b><\/pre>\n
3. Readings<\/h2>\n
\n
4. Tasks<\/h2>\n
\nYou will also need to implement two other functions:
\nvoid syscallsummary_start()<\/tt><\/b>: to start tracing the system calls. All the system calls are invoked after calling this function (and before calling syscallsummary_stop()<\/tt>) will be presented in the system call summary.
\nvoid syscallsummary_stop()<\/tt><\/b>: to stop tracing the system calls.
\nIn other words, these two functions determine the duration in which the system calls are traced.
\nTo help you complete this task, we provide two files, syscalls.txt<\/a> lists all the system calls you will need to trace, and test.c<\/a> demonstrates the usage of the functions you will implement (note that this is only the test file and will not be used for grading).<\/p>\n5. Additional Questions<\/h2>\n
\n
Turn-in Instructions<\/h2>\n
\n
Grading Policy<\/h2>\n
\n