OSDev.org

TheAlmostGenius wrote:After the syscall:

Code: Select all

int $0x80

there is a while loop. Could it be that GCC has optimised this to a hlt instruction? Maybe there is a hlt generated by the compiler. I do know however that I haven't added one in myself. I will try bochs as it is hailed as the better choice for debugging. If it is due to a hlt instruction the compiler has placed in the code, this would mean the int instruction doesn't execute my syscall code.

I would suggest GDB and single stepping, you'll get to know what actually happens. Using debugger is actually quite easy, though means you have to pay attention.

http://wiki.osdev.org/GDB#Using_Emulator_Stubs

The emulator stubs part of the Wiki tells how you start Qemu so it waits for GDB, and below that is how you start GDB. Then just instruct GDB to continue (c) which runs the OS, but first you probably want to set a breakpoint (b) at some point so you can then start single stepping. IIRC you don't want to start single stepping when GDB is started because Qemu will have EIP set to the BIOS code initially, single stepping thru that might take a while, so set a breakpoint to the beginning of your code and then start single stepping from there.

Also you could disassemble your code and see what's there (objdump).

TheAlmostGenius wrote:Could it be that GCC has optimised this to a hlt instruction?

Well, that's pretty easy to check, isn't it? Although it sounds pretty unlikely to me. Having said that, I would turn off optimization in the early days of OS development; speed and size are not big enough problems to counter the ease of debugging that unoptimized code presents.

I will try bochs as it is hailed as the better choice for debugging.

This shouldn't be necessary if you like qemu. It has very good debugging facilities in its monitor, and used in conjunction with gdb probably makes a better debugging platform than Bochs.