Hi, everyone
I'm writing a toy os and come across a problem. The problem can be reproduced like below.
static inline void my_sti()
{
asm volatile("sti\n\t"
"jmp 1f\n\t"
"1: \n\t"
"jmp 2f\n\t"
"2f"
: : :"memory");
}
I find that the second control transfer instruction following the sti MUST trigger an exception, which in turn loads the cs and eip with garbage values. I've also tried ret and call instead of jmp and met the same abnormal behavior. I have no any idea why this happens. I guess the first control transfer instruction doesn't trigger an exception because of the delays of sti. If it would help, I debug my code using bochs + gdb.
The second control transfer instruction following the sti
The second control transfer instruction following the sti
I'm writing a toy os and my current goal is to resemble, simplify and understand the linux kernel. In the early stage, it's designed to be a UP/UMA preemptive kernel and will be extended to support SMP/NUMA etc in the future.
Re: The second control transfer instruction following the st
Not yet. You mean the second control transfer instruction trigger a real exception which need to be handled using IDT?berkus wrote:Have you added proper IDT and dummy interrupt handlers?
Why the jmp instruction could trigger exceptions!!!
I'm writing a toy os and my current goal is to resemble, simplify and understand the linux kernel. In the early stage, it's designed to be a UP/UMA preemptive kernel and will be extended to support SMP/NUMA etc in the future.
Re: The second control transfer instruction following the st
I've added the IDT and it works.berkus wrote:There's just a timer interrupt or any other kind of exception happening the moment you sti, so it triggers the IDT, GPF and triple-fault.harvey wrote:Not yet. You mean the second control transfer instruction trigger a real exception which need to be handled using IDT?berkus wrote:Have you added proper IDT and dummy interrupt handlers?
Why the jmp instruction could trigger exceptions!!!
That is to say, before the code transfers to protected mode, the IF must be cleared. Furthermore, the IF must be set after the IDT is constructed. Is this Right?
I'm writing a toy os and my current goal is to resemble, simplify and understand the linux kernel. In the early stage, it's designed to be a UP/UMA preemptive kernel and will be extended to support SMP/NUMA etc in the future.
Re: The second control transfer instruction following the st
Thanks for your tips. I should've thought it up earlier. I mean there is no any relation with CONTROL TRANSFER thing. CPU can recognize interrupts after the any second instruction following the sti.berkus wrote:Yes, I believe any tutorial would tell you the same.
IDT needs to be constructed AND filled with at least the CPU exception handlers addresses.
I'm writing a toy os and my current goal is to resemble, simplify and understand the linux kernel. In the early stage, it's designed to be a UP/UMA preemptive kernel and will be extended to support SMP/NUMA etc in the future.