CODEWITHSUNDEEP
cassemblygccinterrupt-handlingosdev
JustOneMan
JustOneMan

Reputation: 202

Why Interrupts not generates by C code but easy generates by assembly instructions?

I am programming a little kernel, and implement idt and interrupts.

This C code in my little kernel not generate any interrupt:

int x = 5/0;

int f[4];
f[5] = 8;

But this Assembly code can generate any interrupt:

asm("int $0");

(and handlers work right).

Help me to understand why this situation can happens.

I also tried this:

    int a = 3;
    int b = 3;  
    int c = a-b;
    int x = a/c;

Nothing I try in c code can generate exception for me.

Even this not worked:

int div_by_0(int a, int b){return a/b;}

int x = div_by_0(5, 0);

Upvotes: 1

Views: 454

Answers (3)

Michael Petch
Michael Petch

Reputation: 47593

The problem you are seeing is because division by 0 is undefined behaviour in C/C++. The compiler has managed to do enough optimization at compile time to realize you are dividing by zero. The compiler is free to do anything from things like halting and catching fire to making the result 0. Some compilers will emit a ud2 instruction to raise a CPU exception. The result is undefined.

You have a couple of options. Write your division in assembly and call that function from C/C++. Since you are using GCC (works for CLANG as well) You can also use inline assembly to generate a division by zero with something like:

#include <stdint.h>  /* or replace uint16_t with unsigned short int */ 

void div_by_0 (void)
{
    asm ("div %b0" :: "a"((uint16_t)0));
    return;
}

This sets AX to 0 then divides AX by AL with the DIV instruction. 0/0 is undefined and will raise a Division Exception (#DE). This inline assembly should work with 16, 32, and 64-bit code.

In protected mode or long mode using int $# (Where # is the vector number) to trigger an exception is not always the same as getting a CPU generated exception. Some exceptions generated by the CPU push an error code on the stack after the return address that needs to be cleaned up by an interrupt handler. If you were to use int $0x0d from ring 0 to cause a #GP exception the interrupt handler would likely fault as it returns from the interrupt because using int to generate an exception never places an error code on the stack. This isn't a problem with int $0 because #DE doesn't have an error code placed on the stack by the CPU.

Upvotes: 2

JustOneMan
JustOneMan

Reputation: 202

It turned out to be due to optimization flags. Due to a bit of confusion at Makefiles, the -O2 flag worked. If you enable the -O0 flag, exceptions work directly from C. And even this simple code throws an exceptions:

int x = 5/0;

Upvotes: 1

old_timer
old_timer

Reputation: 71556

void fun ( void )
{
    int a = 3;
    int b = 3;
    int c = a-b;
    int x = a/c;
}

Disassembly of section .text:

0000000000000000 <fun>:
   0:   f3 c3                   repz retq

there is no divide to trigger a divide by zero. It is all dead code.

And none of this has anything to do with the int instruction, these are completely separate topics.

As mentioned in the comments test it without using dead code.

int fun0 ( int x )
{
    return(5/x);
}
int fun1 ( void )
{
    return(fun0(0));
}

but understand that it still may not have the desired effect:

Disassembly of section .text:

0000000000000000 <fun0>:
   0:   b8 05 00 00 00          mov    $0x5,%eax
   5:   99                      cltd   
   6:   f7 ff                   idiv   %edi
   8:   c3                      retq   
   9:   0f 1f 80 00 00 00 00    nopl   0x0(%rax)

0000000000000010 <fun1>:
  10:   0f 0b                   ud2

because the optimizer for fun1 could see the fun0 function. You want to have the code under test in a separate optimization domain. In this case above then the idiv would generate the divide by zero. And then it is becomes an operating system issue as to how that is handled and if it is visible to you.

Upvotes: 4

Related Questions