Interrupts seem to be an issue...

Discussions on more advanced topics such as monolithic vs micro-kernels, transactional memory models, and paging vs segmentation should go here. Use this forum to expand and improve the wiki!
LtG
Member
Member
Posts: 384
Joined: Thu Aug 13, 2015 4:57 pm

Re: Interrupts seem to be an issue...

Post by LtG »

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).
User avatar
iansjack
Member
Member
Posts: 4604
Joined: Sat Mar 31, 2012 3:07 am
Location: Chichester, UK

Re: Interrupts seem to be an issue...

Post by iansjack »

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.
Post Reply