Bochs output

[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?

[Love4Boobies]

What's you inline code? Also, can we see your handler and perhaps the way you set it up?

[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

[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...

[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?

[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.

[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

[djmauretto]

div ax,cl ; diving with 0 error.

Congratulation you are a good asm programmer

[Troy Martin]

The iret is just poping the cs:ip ... while the iretd is popping cs:eip

In other words, iret=real mode and iretd=pmode.

[JamesM]

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".

[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.