/Teaching/Operating Systems/Tutorials/Debugging the SWEB-Kernel with cgd
Debugging the SWEB-Kernel with cgd
sudo apt-get install cgdbto install
Open a second command line and run
make runcgdb(or another debugger you’re preferring
make rungdb/ …)
Wenn diese Befehle nicht funktionieren:
in the directory
utils/gdb/gdbinitthere is a useful
gdb -nx -x utils/gdb/gdbinit -r ../sweb-bin/kernel.x.
Ahhh! How do I get rid of the debug information?
SWEB debugging locking errors debugging
Debugging locking errors with a debugger is much more difficult than without it. This is due to different timings when executing the binary. But there is a different possibility to debug locks by using
debug()-statements. However, Thomas Malcher, wrote an add-on for gdb to apply the so-called Locktree-algorithm onto mutexes in SWEB. Further research has to be done on the efficiency evaluation of this algorithm. Nevertheless, it’s worth a try. Further details can be found on this page in the materials: Debugging SWEB with GDB Lock Tree
Using Eclipse CDT debugger
Compiling the whole project (
make) (this is to assure that the compiled kernel image is in the sweb-bin folder)
Create a new debug configuration (
Debug as) in Eclipse: “C/C++ Remote Application” with the following settings:
…/sweb-bin/kernel.x(choose with browse)
Disable auto build
Debugging Launcher: GDB (SDF) Manual Remote Debugging Launcher
Stop on startup at: startup
Connection: TCP / localhost / 1234
Display in favorites menu: Debug
make qemugdbin the terminal
- now debug with the debug configuration chosen in eclipse before
Choose the appropriate resolution in the grub startup menu
Eclipse would stop the execution of the kernel-image at the
startup function in the file
/sweb/common/source/kernel/main.cpp if set up correctly. This specific breakpoint can be changed in your debug configuration if you want to use different or additional breakpoints.
The demo video can be found here: http://www.youtube.com/watch?v=TXbgYE-lRCU
Debugging using VSCode
If you already know how to debug using VSCode, just get the zipfile and you should be good to go (just make sure your /tmp/sweb folder is empty or does not exist):
- Download the .vscode folder, put it into your source code root folder (the one that contains README.md and the arch, common, userspace folders) (Hint: You have to enable ‘show hidden files‘, on linux systems, files starting with ‘.’ are usually hidden by default)
- Your folder structure should now look something like this: bs23a1/.vscode/settings.json (repository folder name will vary, the .vscode folder contains settings, tasks and launch).
- Install the extensions “C/C++” and “CMake Tools” if you have not done so already.
- In VSCode, open your sweb, more specifically the source code root folder.
- The debug config pauses qemu before starting sweb by default. If you do not need to debug the boot process, you can for example remove the
-S (upper case)flag from
arch/x86/64/CMakeLists.includein the lines after
- In Scheduler.cpp, add a breakpoint in line 52, at the
break;statement just after the
currentThread = *it;line. You can do so by clicking to the left of the line number. There should now be a little red circle to the left of the line number.
- Make sure your /tmp/sweb folder is empty or does not exist.
- Press F5, or alternatively from the menu: Run->Start Debugging.
- VSCode may complain on the first debug run with a popup, you can probably just press ‘cancel’ and debug anyway.
- The qemu window with sweb should now appear, select the first boot entry.
- VSCode should now display line 52 in yellow color (meaning the program flow is halted at that line).
- Open the debug menu on the left (the one with the little bug symbol), click the ‘+‘ symbol in the ‘watch‘ tab.
- In the field that opens, write ‘currentThread‘, press enter.
- It should now write an address next to currentThread, and if you click on it it should show you all members and their current values for currentThread.
- On the bottom, the tab ‘Debug Console’ displays gdb output, where you can also use gdb commands, like “-exec info registers”.
- On the bottom, switch to the tab ‘Terminal‘ and then on the right side, switch to ‘Task‘ to see the sweb debug output. You can open both the debug console and the sweb debug output side-by-side, just drag the fields to where you would like them.
- To restart, close the qemu window or press ctrl+c in the ‘Task’ Terminal, then press F5 again.
- If your IntelliSense is not working, press ctrl+shift+p and run “CMake: Build“. If cmake asks for a kit, select “gcc-9” or similar. If it asks you which task it should use, select “build dbg sweb“.
- Don’t have a flag called ‘DEBUG’ in your debug.h file (make will complain when you try to compile).
Debugging using Clion
Setup to use the debugger:
- Build your SWEB as it is described here. Make sure there is a file called
kernel64.xin your build directory (normally, the build directory is
- Open Clion in your project directory
- In Clion go to
Run -> Edit Configurations... -> Add New Configuration(the ‘+’ in the top left corner)
Remote Debug. After that, the configuration dialogue opens
- Give your debug configuration a name (for example
'target remote' argsthe IP address of the remote debugger needs to be passed. Insert
symbol filepass the path to the
kernel64.xfile. (for example:
- Click on apply
Now the setup should work and you can start debugging. Add the breakpoints to your code you want to observe. Then execute the commands
/tmp/swebin order to start Qemu in debugging mode, in which it waits for the Clion debugger to connect. This is indicated by the line
Guest has not initialized the display (yet).which is printed in Qemu. In the next step, start the debugger in Clion by selecting the previously created debug configuration and clicking on the bug icon. After that, the set breakpoints will stop the program execution once they are hit and you can continue with ordinary debugging. The rest (how to single-step, step-into, etc.) is self-explaining or you can look it up on the internet.