should syscall be trap or interrupt

[ITchimp]

Here is yet another potential bug in james molloy's tutorial...

he registers the syscall 0x80 as an interrupt... should it be a trap instead?

my understanding is that interrupt will return and recompute the instruction that was interrupted...

trap, on the other hand, will return to the instruction after the trapped call...

so by setting the syscall as an interrupt.. the same sys call should get repeatly executed, right?

Is there anything wrong with my logic?

[iansjack]

Is there anything wrong with my logic?

Yes.

The main problem is that you haven't read the Intel manuals.

[ITchimp]

ian, I am your biggest fan!!!

save me some time and shower me with your knowledge and wisdom!!!

[Solar]

You want to shower with the Intel manuals?

That could hurt, you know? The idea is to read them...

[iansjack]

Whilst you are reading the manuals you should check out the sysenter/sysexit instructions, which are a more modern and efficient way of making system calls. (The corresponding instructions in 64-bit mode are syscall/sysret.)

[PeterX]

he registers the syscall 0x80 as an interrupt... should it be a trap instead?

my understanding is that interrupt will return and recompute the instruction that was interrupted...

trap, on the other hand, will return to the instruction after the trapped call...

so by setting the syscall as an interrupt.. the same sys call should get repeatly executed, right?

Is there anything wrong with my logic?

I am aware that there is a destinction between traps and interrupts on other hardware, but I know only x86: On x86 everything is called an "interrupt" no matter if it is from hardware (IRQ), software (system call by interrupt) or an exception (like div 0).

And, no, it does NOT repeat the instruction if you envoke "int 0x80" and return from it. Maybe a introductionary book about x86 Assembler helps?

Greetings
Peter

[bzt]

my understanding is that interrupt will return and recompute the instruction that was interrupted...
trap, on the other hand, will return to the instruction after the trapped call...

It's the other way around. See Gate Types.

An exception is raised during instruction decoding and should trigger a trap gate. That way you can continue the instruction when you return from the ISR (typically a page fault handler).

Interrupts on the other hand checked after instruction decoding and IP adjustment, before starting the decoding of the next instruction (between instructions if you like), and should trigger an interrupt gate. This doesn't really matter except for the "int" instruction, which will save the offset of the next instruction on the stack.

so by setting the syscall as an interrupt.. the same sys call should get repeatly executed, right?
Is there anything wrong with my logic?

Yes and no. Your logic is correct, but it is the trap that restarts the instruction.

Cheers,
bzt

[iansjack]

Oh dear.

This is why I recommend reading the manuals. Traps do not return to the calling instruction - faults do. Both are exceptions rather than interrupts. Whether the IDT entry is a trap or a fault affects the IF flag, not the return address.

Honestly, read the manual and get a far better explanation of interrupts, traps, and faults than you will get here.

[bzt]

Traps do not return to the calling instruction - faults do.

And faults (exceptions) should point to a trap gate, so what is your problem exactly? I wrote "An exception is raised during instruction decoding and should trigger a trap gate." which is 100% accurate.

No offense, but you should read the manuals yourself too. Really not an offense, I agree reading the manual is the best course of action for the OP.

Cheers,
bzt

[nexos]

@ITChimp, here is what they are saying. A fault is an error. The saved eip points to the instruction that caused the fault. A trap points to the next instruction. All interrupts that are not exceptions (except debug exceptions) are traps. An abort, i. e., double fault or machine check, means execution should stop. I am not sure where the saved eip points to during an abort.

[nexos]

To answer your question, a trap is a type of interrupt. The question really is, should a syscall be a trap or exception. The answer is, a trap. The OPs question has once more been lost in the bickering.

[sj95126]

I am not sure where the saved eip points to during an abort.

The Intel programming guide answers that, e.g. for a double fault:

"A program-state following a double-fault exception is undefined."

Meaning you cannot trust what eip points to. It might point to the faulting instruction, or the next instruction, or nowhere.

[8infy]

my understanding is that interrupt will return and recompute the instruction that was interrupted...
trap, on the other hand, will return to the instruction after the trapped call...

It's the other way around. See Gate Types.

An exception is raised during instruction decoding and should trigger a trap gate. That way you can continue the instruction when you return from the ISR (typically a page fault handler).

Interrupts on the other hand checked after instruction decoding and IP adjustment, before starting the decoding of the next instruction (between instructions if you like), and should trigger an interrupt gate. This doesn't really matter except for the "int" instruction, which will save the offset of the next instruction on the stack.

so by setting the syscall as an interrupt.. the same sys call should get repeatly executed, right?
Is there anything wrong with my logic?

Yes and no. Your logic is correct, but it is the trap that restarts the instruction.

Cheers,
bzt

Are you sure? This is the newest intel manual

[bzt]

my understanding is that interrupt will return and recompute the instruction that was interrupted...
trap, on the other hand, will return to the instruction after the trapped call...

An exception is raised during instruction decoding and should trigger a trap gate.
...
it is the trap that restarts the instruction.

Are you sure? This is the newest intel manual
6.5 EXCEPTION classifications

Yes, I'm sure. It doesn't matter what terminology is used, only exceptions can "recompute the instruction that was interrupted", and interrupts (either IRQ or soft-int) "will return to the instruction after", not the other way around. The OP's question was "trap or interrupt", in that context trap clearly meant exception, and interrupt clearly meant soft-int.

And for the OP, there's no way to implement a syscall handler as an exception (trap or not) in any meaningful way. You must use the soft int instruction (neither exception nor trap, but interrupt) which does return to the next instruction for sure, and soft-int won't "recompute the instruction" under no circumstances (or use sysenter/sysexit which is a completely different, non-IDT related mechanism).

Cheers,
bzt

[ITchimp]

Hi, all, I have read the documentation and thought about make the concept clear... here is
my write up on the various concepts involving exception, faults, interrupts and syscall


There are two dimensions:

* the return address of the handler

It is trap if the return address is after the instruction that the trap occur (eg. int 0x80)

It is faults(aka exception) if the instruction causing the faults gets re-executed.

* the trap gate vs interrupt gate

it is trap gate if cpu doesn't disable interrupt before invoking the handler

it is interrupt if cpu disable interrupt before invoking the handler

if the ISR set up code looks like the follows, there is no difference between trap gate and interrupt gate...

Code: Select all

isr0:
   cli 
   push $0
   push $0
   jmp isr_common_stub

if we choose to disable interrupt in software interrupt, there is no difference between trap and interrupt either

that is the most concise version of concept I come up with.