OSDev.org

My simple OS is in assembly lang. It is a .bin file built with nasm. I run the simple OS in qemu on my Ubuntu computer. Qemu uses a hard drive image that loads the .bin file to memory and jumps to it. It is a work in progress. Until now I have been able to troubleshoot problems without a debugger. I now have a problem I haven't been able to troubleshoot. I have been told there is a way to use gdb debugger if I am running in qemu. I have no idea how to do that. Can anyone here tell me how to go about doing it.
TIA Bill S.

First you need to build your executable with debugging information. With assembly code, results are often mixed so you might want to switch to C as early as possible. To compile C code with debug information use -g option. Do not use any automatic optimizations because they often make things difficult to debug. If you use ELF executable file format you'll have to make sure that sections starting with .debug are present. To check if you have your debug information correct, load your ELF image in GDB and try to disassemble some functions (for example command: disasemble /s _start). If you want to use raw binary file, you should link ELF executable file first and then convert it to raw binary (using objcopy or something like that). BTW. QEMU supports loading multiboot compatible ELF files with simple command line option (-kernel <your_kernel.elf>) without even requiring disk image.

To start debugging with QEMU and GDB you'll have to start QEMU with -s and maybe -S option. -s option enables GDB stub in QEMU and then runs as normal. -S option causes GDB to pause execution before executing any code (I think even before BIOS code). To attach your debugger to QEMU, start gdb with your ELF kernel image as parameter (something like: gdb <your_kernel.elf>) and then use target remote tcp::1234 command. After that you should be able to add breakpoints and use GDB as you wish. I like using it with QtCreator.

You can also simply start QEMU with -s and/or -S options and launch GDB without any kernel image, then attach to QEMU but GDB doesn't really work that well without debug information provided.

And additionally, to reduce the kernel size, you can execute these commands with GCC -g option

In QEMU,

And in gdb,

"You can also simply start QEMU with -s and/or -S options and launch GDB without any kernel image, then attach to QEMU "

What do you mean: launch gdb then attach QEMU?

If I do: qemu-system-i386 -s it says 'no bootable device' and it doesn't accept any input. I can't start gdb in the terminal because the terminal has the halted qemu. I simply can't start qemu and then start gdb unless I do it in separate terminals. If I could, after I did I still wouldn't know how to 'attach' qemu. What does 'attach' mean?

The same goes for the qemu -S option.

Bill S.

There is no debugging info. These are nasm .bin files. I would like to step through them and look at the registers.
Bill S.

You have to run QEMU and GDB in separate terminals. 'Attach' means to connect GDB to QEMU (command: 'target remote tcp::1234'). To do simple test, run 'qemu-system-i386 -s -S'. It should say 'Paused' in title bar and not initialize its display. This means that it's waiting for GDB. Then start GDB in other terminal and type 'target remote tcp::1234'.

GDB should output something like this:


GDB doesn't work well with 16 bit code and without debugging information, so you won't be able to disassemble. But you should be able to view registers (using 'info registers' command), step by instructions (using 'nexti' command), set breakpoints etc. You will need to translate addresses between 16 and 32 bit modes yourself if you plan to debug real mode code (as said before, GDB doesn't work well with 16 bit code). And DO NOT use KVM. It will make debugging unreliable.

BTW. You can also use QEMUs built-in monitor. Press CTRL+ALT+2 in QEMU to see it. There you can view registers, Disassemble some code, view memory and much more. You can't set breakpoints there, but you can add some traps in your code and work with that.