Hello. Following this definition of trap:

I would like to known if it's true to say that in x86 (in real mode and other as well) int = trap?
But from this defintion other things than the int-kind (int3, into) instruction can raise trap as well.
And if my guess is right, how can you known if an ISR was invoked because of an trap/fault?
So for instance, I want to write an ISR for #DE which print something when it's invoked by an int $00 or other thing when divide by zero occurs.
The only way I see is to decode the instruction pointed by CS:IP.
But is there a more "elegant" solution?

Software generated exceptions don't clear the interrupt flag.

(This question should probably be in OS Construction.)

CPU manual clearly says for every exception whether it is fault or trap type. So knowing the interrupt vector number tells you whether fault or trap.
Int 01 (debug exception) may cause both, depending on situation, you can distinguish them by checking the value of DR6 and note that when DR6 is clear and no one bit set, then it was icebp hexa opcode F1.
There are also abort type of exception.
#DE is always fault type of exception, the faulting instruction does not complete so CS:IP is pointing to the faulting instruction.
When you execute int 00 (hexa opcode CD 00) then at first CPU performs various checks (e.g. when executed from ring3 whether it does not violate permissions and if it violates then no #DE generated but #GP generated). When this is caused by an exception then it is always delivered through IDT and CPU does not perform privilege checks. So the same vector may be executed on an exception as well as an execution of appropriate INT instruction. For every fault you can decode the instruction at CS:IP and see that it was hexa opcode like CD XX. For traps decoding CS:IP is useless, but there are only very few of traps. Also note that int 03 may be triggered by instruction int3 (hexa opcode CC) as well int 03 (hexa opcode CD 03), here is also the difference that the CD instruction is privilege/permission checked and for the CC the IOPL is not checked. Some exceptions push error code, but when you execute appropriate int (CD XX) instruction then the error code is not pushed so your interrupt handler must care of it to correctly resume the execution (using IRET/IRETQ) so sometimes you must remove the pushed error code from the stack before returning from interrupt and sometimes not. Also note that in IDT descriptor you can define for every interrupt vector whether it is handled through an interrupt gate (then IF is cleared when entering your interrupt handler) or trap gate (IF unaffected).

Ok. Thank you for yours responses. These was of great help to me. But my definition of trap is therefore incorrect because only `int` can trigger it (except for the debug exception of course).
And, I've just tested it:

theses prefix need to be handled as well. I'm not sure about the rep because normally it's an undefined behavior but on my machine it's like a nop.
It's been a long time that no one told me about the icebp instruction .
I'm almost forgotten it.

Being a nop is a perfectly valid case of undefined behaviour for an instruction.

It's one of those weird things about x86 instruction coding. Not all of the ~256^15 possible byte sequences can be accounted for in the decoder circuit. So the makers just throw their hands up in the air and say: fsck it, anything we can't figure out is undefined. It might be nop, it might hang, it might zero the entire RAM, it might overheat and burn, ...

Same for C also, so much undefined behaviour.

Free pizza would be a better option though

There were rumors in the past, where hacker was able to explode monitor with undefined behavior.
But I didn't known for the cpu lol.

Note that they have repurposed rep prefixes to preserve compatibility with old CPUs and giving new features to new CPUs.

Like the 'pause' instruction, or the 'xacquire' prefix.