OSDev.org

i have been using the vbox debug feature to halt, step-into and dump memory features during my development. But last few days, my proj is halted to really weird bug.

This is how debug version of VM is launched.
virtualbox --startvm <vmname> --dbg

Whenever I need to analyze and step through code, I normally put jmp $ and halt and adjust IP by incrementing by 2 to step through. However during the bootloader code debugging, when I do halt from oracle VM, it halt in f000 segment code which is likely to be somewhere in BIOS, probably some interrupt or exception handler. As far as i concerned it was completely random and driving me nuts. It used to halt at where I wanted to be right at the jmp $. The bootloader code (including this jmp $ instruction) runs in 0000:8000h memory area.

It looks like a serious oracle virtual box DEFECT to me but just posted here in case if it rings bell for anyone. I posted in vbox forum but no one knows as debug features are rarely used.

So your bootloader is running into an endless "jmp $" loop, probably with interrupts enabled, some interrupt occurs, is being handled by the BIOS, and while that happens, you halt the simulation using VBox debugger? Doesn't sound surprising that you end up somewhere in the BIOS code (interrupt handler) in such a situation.

yes i started wondering about that too, except that why it never happened before and all started happening all at once. I am going to try with int disabled except when it is needed.

i placed CLI instruction right at the bootloader entry but it still traps into F000 segment. Only places I enable back the interrupts is just before calling INT 21h ( I am not sure if software interrupt needs STI (interrupt to be enable back)). One fishy thing I also observed is that the halt always stops at one particular location:
f000:704e eb fd jmp -3h.
If somehow halt is issued during interrupt processing I expected the halt take place at random addresses, which is not happening here. Therefore although you have brought up really good point, it does not seem to be the case here.

Software interrupts don't care about of the interrupt flag. Is this boot loader running under DOS (because INT 21h is part of the DOS API, not the BIOS API)? Can we see your code? It'd be much easier than to guess.