All necessary tools required for the exercises (and thus for the development of StuBS) are installed in the CIP. Of course you can also work on the assignments at home, we therefore recommend using an up-to-date Linux. Below are some hints on how to configure your Linux system accordingly.
To build StuBS, the C++ source files are compiled using g++ from a current GCC (version > 5) as specified in the Makefile, however The LLVM C++ compiler clang++ can be used as well. Startup code and hardware-related subprograms written in assembly are translated using the Netwide Assembler (nasm). The x86 emulator Qemu is suitable for preliminary testing and, thanks to a built-in debug stub, also for debugging with the GNU Debugger (gdb).
The folder /proj/i4stubs/ in the CIP pool houses additional required files (e.g. for GRUB when building an ISO) and the TFTP directory allowing you to network boot your kernel
uj66ojab@cip6a0:~> git clone https://gitlab.cs.fau.de/i4-exercise/bs/oostubs.git uj66ojab@cip6a0:~> find oostubs oostubs/user/ oostubs/user/app1/ oostubs/user/app1/appl.cc [...]
i4stubs-all@lists.cs.fau.demake in the projects root directory. All .cc and .asm files in this directory are then compiled with the appropriate tools (compiler or assembler) and linked together to a bootable system image. The commands make {kvm,qemu,netboot}{,-gdb}{-dbg,-opt,-noopt,-verbose} are available for testing and debugging.help will give you a detailed overview about its capabilities. uj66ojab@cip6a0:~/oostubs> make help
MAKEFILE for the teaching operating system OOStuBS
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Executing 'make' will compile the operating system from source.
All targets exist in different flavours in addition to <name>:
<name>-noopt, <name>-opt, <name>-dbg, and <name>-verbose.
Targets suffixed with -noopt are compiled without optimizations,
-opt targets produce a highly optimized binary, while
-dbg targets only use optimizations not hindering debugging.
Targets suffixed with -verbose generate binaries including
verbose output (via DBG_VERBOSE), making such targets useful for debugging.
The following targets are available (each target can be suffixed by -noopt und -verbose):
all Builds OOStuBS, generating an ELF binary
netboot Copies OOStuBS to the network share, allowing the test systems to
boot your system
kvm Starts OOStuBS in KVM, a hardware-accelerated virtual machine.
qemu Starts OOStuBS in QEMU. As QEMU is slower than KVM and the real hardware,
some things (especially reace conditions) might behave a little bit different
qemu-gdb Starts OOStuBS in QEMU with activated GDB stub and directly starts
the gdb session to allow step-by-step debugging of your system
kvm-gdb Same as qemu-gdb, but with hardware acceleration
iso Generates a bootable system image (File: .build/stubs.iso)
qemu-iso Starts the system in QEMU by booting from the virtual CD drive
kvm-iso Same as qemu-iso, but with hardware acceleration
usb Generates a bootable USB mass-storage device; the environment variable
USBDEV should point to the USB device.
cd Generates a bootable CD; the environment variable CDRWDEV
should point to the CD writer.
lint Checks the coding style using CPPLINT
Apart from the above targets that run your implementation, our solution can be run
in KVM (at least when called in the CIP) using the target
solution-exercise
where exercise is the number of the exercise whose solution should be executed.
The fastest and easiest way to test your implementation is to run your system image in Qemu with hardware virtualization:
uj66ojab@cip6a0:~/oostubs> make kvm
The QEMU target will by default emulate a system with four cores. For the development of OOStuBS, this does not bother you, because the additional cores are simply ignored. For MPStuBS, only the acceleration provided with the KVM extension will makes your system run really parallel on multiple cores. Hence, this is quite close to the test on real hardware in terms of race conditions and faulty synchronization.
make qemu command instead. In this mode the guest system is only emulated pseudo-parallel, which makes it easier to find more serious bugs, but on the other hand it might mask existing ones that otherwise only occur with make kvm or on real hardware.If you get stuck with simple printf debugging, you can use the debug stub integrated in Qemu and connect a debugger (e.g., gdb) to the emulation. This allows you to easily run your operating system code step by step, easing the detection of the reason for crashes or unwanted behavior. For this purpose the Makefile provides the targets qemu-gdb and kvm-gdb (which can be appended with -dbg for a debug build):
uj66ojab@cip6a0:~/oostubs> make qemu-gdb
In this configuration, the Qemu debug stub waits in the emulator for a socket connection through which a gdb debugger can connect. The debugger will automatically be started so that the gdb prompt appears in the terminal immediately after Qemu is started.
A brief reference of the GDB functions can be found here. If you want detailed instructions on how to use a specific GDB command, you can use the built-in help function in GDB:
(gdb) help <command>
gdb must not be restarted with run, but must be continued with continue instead.For a faster overview of the register and stack contents, we recommend to store this gdbinit under the name .gdbinit in your own home directory.
To test your operating system on the reference hardware in the CIP pool, just use the Makefile target netboot:
uj66ojab@cip6a0:~/oostubs> make netboot
This will compile your StuBS and copy the system image to the TFTP server so that the test hardware can access it with the help of the network boot loader PXELinux. The test hardware automatically boot from the network when they are switched on. In the boot menu that appears, you only have to select the current semester and then the entry with your login name to boot your kernel.
If you are not in the CIP right now, you can still access the hardware via the web interface with the user and password from the lecture. You can start the hardware using the management overview:
Alternatively, you can use the /proj/i4stubs/tools/stubs tool (via SSH) to control the test machines. In case the system will not react on the default actions (On, Off or Reset), try a Hard-Cycle and wait for at least 20 seconds.
You can use VNC to view the contents of the screen and interact with your operating system using keyboard and mouse. If you have no VNC client (like Remmina) at hand, you can also use the web client – just click on the VNC address on the management page:
If you have setup a passwordless SSH login (using a key) on the CIP computers, you can even use the Makefile target netboot from your private PC after adjusting the variable NETBOOTSSH in the common.mk.
-O3, however the resulting machine code can make debugging much more difficult on persistent bugs. For these cases, all the Makefile targets above are also available with the suffix -dbg (use -Og, which enables only optimizations not interfering with debugging) and -noopt (which completely disables the compiler optimizations with -O0): uj66ojab@cip6a0:~/oostubs> make qemu-gdb-dbg
