Page 1 of 1
Bochs output
Posted: Wed Nov 26, 2008 10:18 am
by samoz
Hey guys, I'm trying to implement interrupts now and have some questions.
I can send interrupts out (either with a divide by 0 or using inline assembly) and they look like they are handled properly on the screen, because on my screen, bochs prints out "Interrupt: 3," which is what I programmed.
However, when I look at the bochs console output, it spams out the following message until I turn the machine off:
00013509987e[CPU ] branch_near: offset outside of CS limits
This message only shows up when I use inline assembly to generate the interrupts.
If I put a divide by zero in my code however, it spams the message "interrupt: 0" on screen until I turn the machine off.
Could anyone give me some advice as to why this is happening?
Re: Bochs output
Posted: Wed Nov 26, 2008 10:32 am
by Love4Boobies
What's you inline code? Also, can we see your handler and perhaps the way you set it up?
Re: Bochs output
Posted: Wed Nov 26, 2008 10:45 am
by kmtdk
well
i assume when you have handled the interupt you are just returning "iretd" ( if 32 bit )
The problem is very simple in that content
lets assume it looks like this:
Code: Select all
xor cx,cx
mov ax,0x0001
div ax,cl ; diving with 0 error.
then it execute you handle with at the end does "iretd" with retuns to the address at cs:(e)ip. but the cs:(e)ip is the address where the div happend = a loop .
so to bypass this , as a solution : you will have to know what is the distance regiser ( in the example it is ax), after you have found out, you are suposed to change that regiser to "0" ( if we assume you just would handle the calculation) and then gets the cs:(e)ip, advance ( depending on if it is a 32 bit or a 16 bit) ip to the next instruction .
KMT dk
Re: Bochs output
Posted: Wed Nov 26, 2008 10:50 am
by hailstorm
I agree with kmdtk. Following the Intel specs, a divide by zero is an exception with the classification 'fault'. Faults are, according to the intel manuals, restartable since it can be corrected. The instruction pointer put on the stack still points to the instruction that caused the fault.
Secondly, the reasson why Bochs gives you "branch_near: offset outside of CS limits" has something to do with the jump (eip + offset >= segment limit) or the segment limit of the codesegment is to small. Doesn't have to be a problem though...
Re: Bochs output
Posted: Wed Nov 26, 2008 4:44 pm
by samoz
OK, the divide by zero error makes sense then if it just keeps jumping back to where it was before.
However, I'm still confused about the other error message. You mentioned using the iretd command, but I'm following James M's tutorials, which uses the iret command. Could this be causing problems?
Also something I noticed in my bochs output was the all my segments are stored in segments 3&4 (user mode) segments of my GDT, when previously they were in segments 1&2 (system mode). Would this be causing problems as well?
Re: Bochs output
Posted: Wed Nov 26, 2008 4:47 pm
by tantrikwizard
You mentioned using the iretd command, but I'm following James M's tutorials, which uses the iret command. Could this be causing problems?
It depends on the compiler. Use iretd to be safe.
Re: Bochs output
Posted: Thu Nov 27, 2008 11:17 am
by kmtdk
The iret is just poping the cs:ip (but as tantrikwizard said:
It depends on the compiler...
)
while the iretd is popping cs:eip
That should be the reason, if not we will need the souce code, to tell you excatly the problem.
KMT dk
Re: Bochs output
Posted: Fri Nov 28, 2008 3:28 am
by djmauretto
kmtdk wrote:div ax,cl ; diving with 0 error.
Congratulation you are a good asm programmer
Re: Bochs output
Posted: Fri Nov 28, 2008 10:10 am
by Troy Martin
kmtdk wrote:The iret is just poping the cs:ip ... while the iretd is popping cs:eip
In other words, iret=real mode and iretd=pmode.
Re: Bochs output
Posted: Fri Nov 28, 2008 10:30 am
by JamesM
tantrikwizard wrote:You mentioned using the iretd command, but I'm following James M's tutorials, which uses the iret command. Could this be causing problems?
It depends on the compiler. Use iretd to be safe.
No it doesn't. If anything it depends on the assembler, which it doesn't in this case. It's the same as using "mov" instead of "movl".
Re: Bochs output
Posted: Fri Nov 28, 2008 12:55 pm
by tantrikwizard
"No it doesn't. If anything it depends on the assembler, which it doesn't in this case. It's the same as using "mov" instead of "movl"."
Try researching some different compilers. I said this from experience.
most 32-bit compilers produce the 32-bit version of this code:
Code: Select all
__declspec(naked)
void ISR0(){
__asm{ iret }
}
However, Open Watcom's WCL386 does not even though it's a 32-bit compiler. If this code appears in a module with other code, every piece of that module will compile to 32-bit except for this ISR0()'s iret statement. It produced the the 16 version (cs:ip) and adds the instruction size prefix to the opcode (0x66) even though everything is compiled for 32-bit code. You must specify iretd to get the 32-bit version. You are partially right in that it can depend on assembler, not only the assembler but also the type of code segment. In a 16-bit code segement iret will normally produce the 16 bit version (cs:ip). The same assembler will often produce the 32-bit version using the same iret instruction if it appears in a code32 segment so it's unclear which is being produced.
samoz stated the program was running in protected mode. I have no reason not to believe him. The output depends on the compiler, use iretd to be safe.
P.S. "movl" is not a valid instruction on most assemblers.