Experiment Objective 1.Be familiar with Subversion (SVN) and GDB (the GNU Debugger) 2.Setup your account to work on OS161 3 the source code structure of OS161 4.Know how to build the OS161 kernel from source 5.Learn how to modify the OS161 kernel by adding debugging statements and system calls

Install OS/161, Sys/161 and the toolchain 2.Learn how to modify it, build it, run it, and debug it 3.Customize the Kernel Boot Output 4.Add a Kernel Menu Command

Environment: Ubuntu 14.04 Compiler: GCC MIPS cross-compiler GDB for Use with OS/161 Bmake

The experimental data are from the CS350 operating system course of Harvard University. OS161 is a simple operating system developed by Harvard specially for learning and practicing. OS161 is divided into two parts, kernel and user are stored in the installation folder. The kernel folder contains the core files of the OS, while those not in the kernel are public files. In the installation directory make compiles all the public information, including the test program and so on, basically at the user level. In kernel/ASSTX/compile, make recompiles the entire OS161 file, but in contrast, if you add files to the kernel, you need to modify the configuration in the kernel/conf to compile it correctly. (We use a simulator in CS350 because it allows everyone to have a private machine on which to test their operating system. In addition, debugging and testing the operating system on the simulator is easier than it would be on real hardware. The System/161 machine simulator has been found to be an excellent platform for rapid development of operating system code, while still retaining a high degree of realism. Apart from floating point support and certain issues relating to RAM cache management, it provides an accurate emulation of a MIPS R3000 processor.)

The source files involved in Sys161 kernel are kprintf.c, main.c,menu.c, and lib.h, which are located in os161-1.99/kern/startup. 1) Kprintf (” Put your group-name… “, “Put your group-name…”) Change to your own user name. 2) The second experiment required setting up a new function DTH, so that the DOS interface can output debugging information for a given thread. The function DTH is displayed in the sub_menu selection screen. By analyzing the menu.c file, we can find that we can refer to the existing CMD function series, write a function about DTH by ourselves, and establish the corresponding selection interface in CMDtable. DB_THREADS () DB_THREADS () DB_THREADS () DB_THREADS () This debug message comes from a kernel global variable dbFlags, This variable defines which types of debugging messages should be displayed when the kernel runs. DB_THREADS is defined as 0x0010 in the lib.h file. Since then, we can see that assigning dbFLAGS to DB_THREADS in the DTH function will do the job.

3. Experiment Result 1) Add the DTH command option in menu

2) Custom cmD_dTH function in menu

3) Output of final results

4. Problems and solutions The biggest problem in this experiment is not adding command functions, but installing and configuring the environment. 1) GDB installation in Step5 reported an error Error2 after mutual communication, we found that the reason was that libncurses-devel library was not installed on the original computer, and the above operation still failed according to the instructions, so we directly downloaded the required files after Google.

2) there is no corresponding bin file in Step7, and bmake does not define an error when you run the ln command. After some searching and trying, it was found that there were two lines of sh statement in the guide book, but there was no explanation between the two lines, which could easily be mistaken as two commands, and the echo statement could not be executed all the time. All correct execution statements are as follows: sh — cs ‘for I in MIPS -*; do ln -s $HOME/sys161/tools/bin/$i $HOME/sys161/bin/cs350-echo $i | cut -d- -f4-; done’

3) An error occurs when executing the statement after closing the terminal: The sys161 statement is not defined. After discussion, we found that, according to the commands in the instruction book, when configuring environment variables and PATH in Step3, we only added the command PATH to the current terminal interface without changing the entire ubuntu environment. Therefore, after closing the terminal, the system could not access the corresponding PATH of the command. The command could not be executed. There are three ways to change a path by directly adding a path to the /etc/environment directory. However, in this experiment, the directory is read-only, so no path can be added. Export PATH=$HOME/sys161/tools/bin:$PATH =$HOME/sys161/tools/bin:$PATH This approach takes effect immediately, but is only suitable for temporary variables. Add PATH to /etc/profile (so it works for all users) or add PATH to the end of the file in terminal gedit ~/.profile (or.bashrc). (Only valid for the current user.) The following figure shows how to resolve the problem