Page 1 of 2
system call function
Posted: Wed Dec 03, 2003 7:45 pm
by 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?
Re:system call function
Posted: Wed Dec 03, 2003 10:49 pm
by 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");
}
Re:system call function
Posted: Thu Dec 04, 2003 2:22 am
by 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.
Re:system call function
Posted: Thu Dec 04, 2003 8:06 pm
by 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?
Re:system call function
Posted: Fri Dec 05, 2003 5:23 am
by Ozguxxx
Why are you acknowledging interrupt controller at the end of void system_call(){} ? Is this an hardware interrupt handler? Good luck.
Re:system call function
Posted: Fri Dec 05, 2003 7:45 am
by Pype.Clicker
northfuse wrote:
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

Re:system call function
Posted: Fri Dec 05, 2003 9:34 am
by Ozguxxx
Hey, I might be missing something but can soebody tell me why is it necessary to acknowledge pic to call interrupt 81? Thanx...
Re:system call function
Posted: Fri Dec 05, 2003 10:55 am
by Pype.Clicker
The pic shouldn't be acknowledged for software-called interrupts. Only for IRQs ...
Re:system call function
Posted: Fri Dec 05, 2003 11:34 am
by 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?
Re:system call function
Posted: Fri Dec 05, 2003 11:42 am
by Tim
No, it's not. It's only necessary for interrupts caused by IRQs.
Re:system call function
Posted: Fri Dec 05, 2003 5:15 pm
by 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.
Re:system call function
Posted: Fri Dec 05, 2003 5:36 pm
by 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.
Re:system call function
Posted: Fri Dec 05, 2003 11:31 pm
by Chris Giese
northfuse wrote:
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.
Re:system call function
Posted: Sat Dec 06, 2003 3:11 am
by 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?
Re:system call function
Posted: Sat Dec 06, 2003 4:27 am
by 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.