system call function

[northfuse]

ok, i'm trying to see if i can get a system interrupt to work. but, whenever i call the interrupt (int 81), interrupt runs (which is good), but then it triple faults. Bochs gives the response that

Code: Select all

fetch_raw_descriptor: LDTR.valid=0

then after continuing

Code: Select all

iret: AR byte indicated non code segment

it is running in a code segment (i've checked my GDT and its right). what might be wrong?

[Chris Giese]

>fetch_raw_descriptor: LDTR.valid=0
>iret: AR byte indicated non code segment

This sounds like IRET is popping junk into the CS register.
Can you use the Bochs debugger to set a breakpoint there and check it?

You're not doing something like this, are you?

Code: Select all

/* How NOT to write an interrupt handler in GCC: */
void my_interrupt_handler(void) {
   /* do something */
   __asm__("iret");
}

[Pype.Clicker]

LDTR.valid=0 will be reported by BOCHS when you attempt to load a descriptor with an LDT selector (bit 2 set) while you haven't do any LLDT yet ...

Chris Griese likely pinpointed your problem... check your stack pushes/pops if you have a stub function in ASM, and do a stub function in ASM if you don't have one already ...

C functions automatically embrace your code with <push ebp; mov ebp, esp> and <mov esp, ebp> ... so trying to write an IRET in C code will fail.

Code: Select all

    push ebp
    mov ebp,esp

    pushad ;; resulting of a asm("pushad"); on first line
    ;; C code comes here
    popad ;; guess why
    iret

    mov esp,ebp
    ret

cannot work. period.

[northfuse]

this is my isr:

Code: Select all

;; system interrupts
[extern system_call]
[global system_call_isr]
system_call_isr:
   pusha
   push ds
   pushes
   push fs
   push gs
   mov eax,0x10   ;data segment
   mov ds, eax
   mov ds, eax
   cld
   call system_call
   pop gs
   pop fs
   pop es
   pop ds
   popa
   iret

Code: Select all

void system_call() {
   screen_put_string("system interrupt called\n");
   outportb(0x20, 0x20);
}

The isr is added to the IDT at index 81 with settings of 0xEF00. Present, ring0, trap gate. I don't get why its telling me something about the LDT. I don't have one, but i thought they were optional?

[Ozguxxx]

Why are you acknowledging interrupt controller at the end of void system_call(){} ? Is this an hardware interrupt handler? Good luck.

[Pype.Clicker]

this is my isr:
The isr is added to the IDT at index 81 with settings of 0xEF00. Present, ring0, trap gate. I don't get why its telling me something about the LDT. I don't have one, but i thought they were optional?

Did you read this ?

LDTR.valid=0 will be reported by BOCHS when you attempt to load a descriptor with an LDT selector (bit 2 set) while you haven't do any LLDT yet ...

Indeed, the LDT is optionnal, but if some garbage is loaded in a segment register, the CPU might try to locate the LDT (because the selector is requesting so).

Btw, did you load IDT#81 with a pointer to system_call or system_call_isr ? (i know it's a dumb question ... i don't think you might have loaded system_call on purpose ... it's just in case).
Your ISR code looks correct, except for the "pushes" which is likely to be a typo

[Ozguxxx]

Hey, I might be missing something but can soebody tell me why is it necessary to acknowledge pic to call interrupt 81? Thanx...

[Pype.Clicker]

The pic shouldn't be acknowledged for software-called interrupts. Only for IRQs ...

[Ozguxxx]

So why is that so?

Code: Select all

void system_call() {
   screen_put_string("system interrupt called\n");
   outportb(0x20, 0x20); 
}

In that code outportb(0x20,0x20) is acknowledging master pic right? Is that necesary?

[Tim]

No, it's not. It's only necessary for interrupts caused by IRQs.

[northfuse]

i got rid of the outportb call, and changed 'pushes' to 'push es' and it worked! couldn't find out what the pushes call meant, though. nasm didn't complain about it.

[Tim]

That's weird. I assembled your old interrupt handler, with the PUSHES instruction. It assembled with no errors, but in the disassembly, I saw that NASM had ignored that line.

Code: Select all

E:\>type temp.asm
[bits 32]
[extern system_call]
[global system_call_isr]
system_call_isr:
   pusha
   push ds
   pushes
   push fs
   push gs
   mov eax,0x10   ;data segment
   mov ds, eax
   mov ds, eax
   cld
   call system_call
   pop gs
   pop fs
   pop es
   pop ds
   popa
   iret

E:\>nasm -f win32 temp.asm -o temp.obj

E:\>objdump -d temp.obj

temp.obj:     file format pe-i386

Disassembly of section .text:

00000000 <.text>:
   0:   60                      pusha
   1:   1e                      push   %ds
   2:   0f a0                   push   %fs
   4:   0f a8                   push   %gs
   6:   b8 10 00 00 00          mov    $0x10,%eax
   b:   8e d8                   mov    %eax,%ds
   d:   8e d8                   mov    %eax,%ds
   f:   fc                      cld
  10:   e8 00 00 00 00          call   15 <.text+0x15>
  15:   0f a9                   pop    %gs
  17:   0f a1                   pop    %fs
  19:   07                      pop    %es
  1a:   1f                      pop    %ds
  1b:   61                      popa
  1c:   cf                      iret

E:\>

In summary: Don't write PUSHES. It might assemble, but it's not an instruction.

[Chris Giese]

i got rid of the outportb call, and changed 'pushes' to 'push es' and it worked! couldn't find out what the pushes call meant, though. nasm didn't complain about it.

Arrrgh! NASM didn't complain because it thought "pushes" was a label. This behavior caught me too, once.

Feature or bug? Discuss.

"nasm -w+orphan-labels ..." will generate warnings for labels that don't end with colons.

[Ozguxxx]

Well, very UNfortunate to me that this is NOT a bug. Are there anybody who is used to use label without colons in nasm?

[df]

i ALWAYS put colons on my labels. to me, thats what makes it a label! i dont like 'loose labels' like nasm lets you do. ugh.