Tools ===== You'll use two sets of tools in this class: an x86 emulator, `QEMU <#qemu>`__, for running your kernel; and a `compiler toolchain <#chain>`__, including assembler, linker, C compiler, and debugger, for compiling and testing your kernel. This page has the information you'll need to download and install your own copies. This class assumes familiarity with Unix commands throughout. It should be possible to get this development environment running under windows with the help of `Cygwin `__. Install cygwin, and be sure to install the flex and bison packages (they are under the development header). Installation ------------ Using a Virtual Machine ~~~~~~~~~~~~~~~~~~~~~~~ Otherwise, the easiest way to get a compatible toolchain is to install a modern Linux distribution on your computer. With platform virtualization, Linux can cohabitate with your normal computing environment. Installing a Linux virtual machine is a two step process. First, you download the virtualization platform. 1. Download and install Virtualbox/Vagrant - Download and install the latest version of `virtualbox `__ - Download and install the latest version of `vagrant `__ - (Windows only, as ssh client) Download and install `git `__ - Ubuntu users may also use the following commands to get virtualbox and vagrant. .. code-block:: sh [host] $ apt-get install virtualbox [host] $ apt-get install vagrant .. .. admonition:: Note - It is optional to use vagrant for our labs. You can use virtualbox only. - If you decide to use virtualbox only. 1) you could download Ubuntu desktop `here `__ like ubuntu-14.04.3-desktop-i386.iso. 2) Start up your virtualization platform and create a new (32-bit) virtual machine. Use the downloaded Ubuntu image as a boot disk 3) Follow all steps that described below except vagrant parts. .. 2. Add guest OS and run the VM **(Vagrant's user only)** .. code-block:: sh # add 32-bit VM [host] $ vagrant box add ubuntu/trusty32 # Access the VM [host] $ mkdir cs3210 [host] $ vagrant init ubuntu/trusty32 [host] $ vagrant up [host] $ vagrant ssh 3. Once you have the VM up and running, initialize your VM for this course: .. code-block:: sh # in VM, install git [VM] $ sudo apt-get install git [VM] $ mkdir ~/cs3210 [VM] $ cd ~/cs3210 4. If you haven't previously, create an ssh key and upload it to github.gatech.edu by following the instructions here: https://help.github.com/articles/generating-an-ssh-key/. Then clone your repo replacing YOUR-USERNAME with your github username. .. code-block:: sh # it's time for setting up your environment [vm] $ git clone git@github.gatech.edu:cs3210-fall2017/cs3210-lab-YOUR-USERNAME lab Cloning into lab... $ cd lab QEMU Emulator ~~~~~~~~~~~~~ `QEMU `__ (`manual `__) is a modern and fast PC emulator. - Installing QEMU - Most GNU/Linux distributions have simple installation processes based on package repositories. It is often best to use the repository approach for installing QEMU, as you can be confident that it will just install and run. .. code-block:: sh [VM] $ apt-get install qemu libvirt-bin - Compilation from the source - You might prefer to install QEMU by compiling the source code, which is available `on the QEMU website `__ 1. First you must decompress the sources: .. code-block:: sh [VM] $ cd /tmp [VM] $ tar -zxvf qemu-x.y.z.tar.gz [VM] $ cd qemu-x.y.z 2. Configure QEMU and build it .. code-block:: sh [VM] $ ./configure [VM] $ make 3. **Make** to install QEMU in /usr/local .. code-block:: sh [VM] $ make install Tool Guide ---------- Familiarity with your environment is crucial for productive development and debugging. This page gives a brief overview of the JOS environment and useful GDB and QEMU commands. Don't take our word for it, though. Read the GDB and QEMU manuals. These are powerful tools that are worth knowing how to use. .. admonition:: Index Debugging tips: - `Kernel <#kernel>`__ - `User environments <#user-environments-lab-3>`__ Reference: - `JOS makefile <#jos-makefile>`__ - `JOS obj/ <#jos-obj>`__ - `GDB <#gdb>`__ - `QEMU <#qemu>`__ Debugging tips -------------- Kernel ~~~~~~ GDB is your friend. Use the `qemu-gdb <#make-qemu-gdb>`__ target (or its `qemu-gdb-nox <#make-qemu-gdb-nox>`__ variant) to make QEMU wait for GDB to attach. See the `GDB <#gdb>`__ reference below for some commands that are useful when debugging kernels. If you're getting unexpected interrupts, exceptions, or triple faults, you can ask QEMU to generate a detailed log of interrupts using the `-d <#qemu--d>`__ argument. To debug virtual memory issues, try the QEMU monitor commands `info mem <#qemu-info-mem>`__ (for a high-level overview) or `info pg <#qemu-info-pg>`__ (for lots of detail). Note that these commands only display the *current* page table. **(Lab 4+)** To debug multiple CPUs, use GDB's thread-related commands like `thread <#gdb-thread>`__ and `info threads <#gdb-info-threads>`__. User environments (lab 3+) ~~~~~~~~~~~~~~~~~~~~~~~~~~ GDB also lets you debug user environments, but there are a few things you need to watch out for, since GDB doesn't know that there's a distinction between multiple user environments, or between user and kernel. You can start JOS with a specific user environment using `make run-\ *name* <#make-run>`__ (or you can edit ``kern/init.c`` directly). To make QEMU wait for GDB to attach, use the `run-\ *name*-gdb <#make-run-x>`__ variant. You can symbolically debug user code, just like you can kernel code, but you have to tell GDB which `symbol table <#obj-elf>`__ to use with the `symbol-file <#gdb-symbol-file>`__ command, since it can only use one symbol table at a time. The provided ``.gdbinit`` loads the kernel symbol table, ``obj/kern/kernel``. The symbol table for a user environment is in its ELF binary, so you can load it using symbol-file obj/user/\ *name*. *Don't* load symbols from any ``.o`` files, as those haven't been relocated by the linker (libraries are statically linked into JOS user binaries, so those symbols are already included in each user binary). Make sure you get the *right* user binary; library functions will be linked at different EIPs in different binaries and GDB won't know any better! **(Lab 4+)** Since GDB is attached to the virtual machine as a whole, it sees clock interrupts as just another control transfer. This makes it basically impossible to step through user code because a clock interrupt is virtually guaranteed the moment you let the VM run again. The `stepi <#gdb-si>`__ command works because it suppresses interrupts, but it only steps one assembly instruction. `Breakpoints <#gdb-b>`__ generally work, but watch out because you can hit the same EIP in a different environment (indeed, a different binary altogether!). Reference --------- JOS makefile ~~~~~~~~~~~~ The JOS Makefile includes a number of phony targets for running JOS in various ways. All of these targets configure QEMU to listen for GDB connections (the ``*-gdb`` targets also wait for this connection). To start once QEMU is running, simply run gdb from your lab directory. We provide a ``.gdbinit`` file that automatically points GDB at QEMU, loads the kernel symbol file, and switches between 16-bit and 32-bit mode. Exiting GDB will shut down QEMU. make qemu Build everything and start QEMU with the VGA console in a new window and the serial console in your terminal. To exit, either close the VGA window or press ``Ctrl-c`` or ``Ctrl-a x`` in your terminal. make qemu-nox Like ``make qemu``, but run with only the serial console. To exit, press ``Ctrl-a x``. This is particularly useful over SSH connections to Athena dialups because the VGA window consumes a lot of bandwidth. make qemu-gdb Like ``make qemu``, but rather than passively accepting GDB connections at any time, this pauses at the first machine instruction and waits for a GDB connection. make qemu-nox-gdb A combination of the ``qemu-nox`` and ``qemu-gdb`` targets. make run-\ *name* (Lab 3+) Run user program *name*. For example, ``make run-hello`` runs ``user/hello.c``. make run-\ *name*-nox, run-\ *name*-gdb, run-\ *name*-gdb-nox, (Lab 3+) Variants of ``run-name`` that correspond to the variants of the ``qemu`` target. The makefile also accepts a few useful variables: make V=1 ... Verbose mode. Print out every command being executed, including arguments. make V=1 grade Stop after any failed grade test and leave the QEMU output in ``jos.out`` for inspection. make QEMUEXTRA='*args*\ ' ... Specify additional arguments to pass to QEMU. JOS obj/ ~~~~~~~~ When building JOS, the makefile also produces some additional output files that may prove useful while debugging: ``obj/boot/boot.asm``, ``obj/kern/kernel.asm``, ``obj/user/hello.asm``, etc. Assembly code listings for the bootloader, kernel, and user programs. ``obj/kern/kernel.sym``, ``obj/user/hello.sym``, etc. Symbol tables for the kernel and user programs. ``obj/boot/boot.out``, ``obj/kern/kernel``, ``obj/user/hello``, etc Linked ELF images of the kernel and user programs. These contain symbol information that can be used by GDB. GDB ~~~ See the `GDB manual `__ for a full guide to GDB commands. Here are some particularly useful commands for cs3210, some of which don't typically come up outside of OS development. Ctrl-c Halt the machine and break in to GDB at the current instruction. If QEMU has multiple virtual CPUs, this halts all of them. c (or continue) Continue execution until the next breakpoint or ``Ctrl-c``. si (or stepi) Execute one machine instruction. b function or b file\:line (or breakpoint) Set a breakpoint at the given function or line. b \*\ *addr* (or breakpoint) Set a breakpoint at the EIP *addr*. set print pretty Enable pretty-printing of arrays and structs. info registers Print the general purpose registers, ``eip``, ``eflags``, and the segment selectors. For a much more thorough dump of the machine register state, see QEMU's own ``info registers`` command. x/\ *N*\ x *addr* Display a hex dump of *N* words starting at virtual address *addr*. If *N* is omitted, it defaults to 1. *addr* can be any expression. x/\ *N*\ i *addr* Display the *N* assembly instructions starting at *addr*. Using ``$eip`` as *addr* will display the instructions at the current instruction pointer. symbol-file *file* **(Lab 3+)** Switch to symbol file *file*. When GDB attaches to QEMU, it has no notion of the process boundaries within the virtual machine, so we have to tell it which symbols to use. By default, we configure GDB to use the kernel symbol file, ``obj/kern/kernel``. If the machine is running user code, say ``hello.c``, you can switch to the hello symbol file using ``symbol-file obj/user/hello``. .. admonition:: info QEMU represents each virtual CPU as a thread in GDB, so you can use all of GDB's thread-related commands to view or manipulate QEMU's virtual CPUs. thread *n* GDB focuses on one thread (i.e., CPU) at a time. This command switches that focus to thread *n*, numbered from zero. info threads List all threads (i.e., CPUs), including their state (active or halted) and what function they're in. QEMU ~~~~ QEMU includes a built-in monitor that can inspect and modify the machine state in useful ways. To enter the monitor, press Ctrl-a c in the terminal running QEMU. Press Ctrl-a c again to switch back to the serial console. For a complete reference to the monitor commands, see the `QEMU manual `__. Here are some particularly useful commands: xp/\ *N*\ x *paddr* Display a hex dump of *N* words starting at *physical* address *paddr*. If *N* is omitted, it defaults to 1. This is the physical memory analogue of GDB's ``x`` command. info registers Display a full dump of the machine's internal register state. In particular, this includes the machine's *hidden* segment state for the segment selectors and the local, global, and interrupt descriptor tables, plus the task register. This hidden state is the information the virtual CPU read from the GDT/LDT when the segment selector was loaded. Here's the CS when running in the JOS kernel in lab 1 and the meaning of each field: :: CS =0008 10000000 ffffffff 10cf9a00 DPL=0 CS32 [-R-] ``CS =0008`` The visible part of the code selector. We're using segment 0x8. This also tells us we're referring to the global descriptor table (0x8&4=0), and our CPL (current privilege level) is 0x8&3=0. ``10000000`` The base of this segment. Linear address = logical address + 0x10000000. ``ffffffff`` The limit of this segment. Linear addresses above 0xffffffff will result in segment violation exceptions. ``10cf9a00`` The raw flags of this segment, which QEMU helpfully decodes for us in the next few fields. ``DPL=0`` The privilege level of this segment. Only code running with privilege level 0 can load this segment. ``CS32`` This is a 32-bit code segment. Other values include ``DS`` for data segments (not to be confused with the DS register), and ``LDT`` for local descriptor tables. ``[-R-]`` This segment is read-only. info mem **(Lab 2+)** Display mapped virtual memory and permissions. For example, :: ef7c0000-ef800000 00040000 urw efbf8000-efc00000 00008000 -rw tells us that the 0x00040000 bytes of memory from 0xef7c0000 to 0xef800000 are mapped read/write and user-accessible, while the memory from 0xefbf8000 to 0xefc00000 is mapped read/write, but only kernel-accessible. QEMU also takes some useful command line arguments, which can be passed into the JOS makefile using the `QEMUEXTRA <#make-qemuextra>`__ variable. make QEMUEXTRA='-d int' ... Log all interrupts, along with a full register dump, to ``qemu.log``. You can ignore the first two log entries, "SMM: enter" and "SMM: after RMS", as these are generated before entering the boot loader. After this, log entries look like :: 4: v=30 e=0000 i=1 cpl=3 IP=001b:00800e2e pc=00800e2e SP=0023:eebfdf28 EAX=00000005 EAX=00000005 EBX=00001002 ECX=00200000 EDX=00000000 ESI=00000805 EDI=00200000 EBP=eebfdf60 ESP=eebfdf28 ... The first line describes the interrupt. The ``4:`` is just a log record counter. ``v`` gives the vector number in hex. ``e`` gives the error code. ``i=1`` indicates that this was produced by an ``int`` instruction (versus a hardware interrupt). The rest of the line should be self-explanatory. See `info registers <#qemu-info-registers>`__ for a description of the register dump that follows. Note: If you're running a pre-0.15 version of QEMU, the log will be written to ``/tmp`` instead of the current directory. -------------- Questions or comments regarding cs3210? Send e-mail to the TAs at `*cs3210-staff@cc.gatech.edu* `__. .. raw:: html .. raw:: html