OSDev.org

This is something that has been troubling me, someone here maybe can help me. This is basic stuff which i'm trying to get to work and learn, but I cannot find anything i'm afraid.

Right now, I have a interrupt handler which looks something like this in pseudo-code (a regular basic interrupt handler). This is where it jumps on an interrupt.

First the ASM handler: C handler ASM interrupt handler last part: It works as well, no problems with context-switching and so on...
When however a system call is invoked, I have to remove the saving/loading of registers into the PCB (that is, an if-clause is added that doesn't save the PCB if it's a system call). First I didn't know why I had to do this, so I simply removed the lines that saved/loaded the PCB state with an if-clause like mentioned, because I thought it probably anyways will come back to the same process after a system call. That worked, and my logic is probably correct. But I cannot do that now anymore, because I have to implement a thing that needs to load a new PCB directly after a certain system call has been made.

I realise now that when a system call is invoked, the registers have to be saved in some other way? Because when I do a system call and save its registers I realised that when it later comes back to the process which invoked the system call, it seems that the EPC and all other registers weren't saved correctly. In other words, how do you save the PCB state when doing a system call?

Thankful for help : )

I realise now that when a system call is invoked, the registers have to be saved in some other way?

No, generally it's wise to make all kernel entries from user space do the same thing. So user mode traps, interrupts from user mode and system calls should all put the PCB in the same state. That way, whether a process is pre-empted during ISR, syscall or trap it may later be restarted the same way.

The most common method I would think is to point the interrupt stack pointer into the PCB so that when the interrupt occurs the processor begins pushing stuff automatically into the PCB. The ISR or syscall can then push the general purpose regs into the PCB.

That saves the copying that you're doing.

To resume just point the stack at the correct place in the PCB, pop the regs and do an IRET.

There's no automatic pushing on MIPS. I assume this is on MIPS, since he mentioned "Increase EPC with 4".

Just make sure you don't save the registers in the same place if an interrupt happens when inside a system call.

Oh, I assumed it was x86 when I saw the iret....

Gigasoft wrote:There's no automatic pushing on MIPS. I assume this is on MIPS, since he mentioned "Increase EPC with 4".

Just make sure you don't save the registers in the same place if an interrupt happens when inside a system call.

Right, i'm on MIPS. So interrupts can happen during a system call? I thought you had to use eret before a new interrupt can occur. That's troubling : /

gerryg400 wrote:Oh, I assumed it was x86 when I saw the iret....

Ah sorry about that.

While I'm not able to say anything specifically for MIPS (Not within my experience), I would expect that, like most RISC architectures, there are two possibilities:

• The system call instruction shares resources with exception and interrupt handling (e.g. the registers used to store processor status). In this case, I would expect the processor to disable interrupts when taking one to prevent you from losing them
• The system call instruction uses dedicated resources/shares resources with normal program flow. In this case, you would need to disable interrupts manually if you needed to but wouldn't have to worry about an interrupt taking out the data.

From what you've said (i.e. eret) I would expect the former, but as said, I don't have MIPS experience. Read the manuals.