When a hardware interrupt is generated, usually all register values are saved on the kernel stack...
but I have seen, in minix 3.1 that eax ebx, ecx, edx , est are not saved at all, only esi is preserved,
also I have seen in some context switch code, that the registers are not saved at all,,,
what are the considerations for determining whether registers should be saved, and if so, which ones?
register preservation considerations across syscalls
Re: register preservation considerations across syscalls
You are mistaken.
The interrupt handlers in Minix 3 all use the macro SAVE_PROCESS_CTX: https://github.com/Stichting-MINIX-Rese ... _asm.S#L21
This, in turn, uses another macro SAVE_GP_REGS: https://github.com/Stichting-MINIX-Rese ... onst.h#L83
This macro saves EAX, ECX, EDX, EBX, ESI, and EDI: https://github.com/Stichting-MINIX-Rese ... .h#L51-L56
The interrupt handlers in Minix 3 all use the macro SAVE_PROCESS_CTX: https://github.com/Stichting-MINIX-Rese ... _asm.S#L21
This, in turn, uses another macro SAVE_GP_REGS: https://github.com/Stichting-MINIX-Rese ... onst.h#L83
This macro saves EAX, ECX, EDX, EBX, ESI, and EDI: https://github.com/Stichting-MINIX-Rese ... .h#L51-L56
Re: register preservation considerations across syscalls
I am talking about the version 3.1 of minix, you re referring to 3.3 version which switches from segment based
multitasking to paging... we are not talking bout the same version of minix
multitasking to paging... we are not talking bout the same version of minix
Re: register preservation considerations across syscalls
The code I linked is in Minix 3.1.6: https://github.com/Stichting-MINIX-Rese ... .h#L50-L56
Prior that, pushad was used: https://github.com/Stichting-MINIX-Rese ... 386.s#L325
This save function is called by all the hardware interrupt handlers: https://github.com/Stichting-MINIX-Rese ... 386.s#L217
(The counterpart popad is found here: https://github.com/Stichting-MINIX-Rese ... 386.s#L401)
Prior that, pushad was used: https://github.com/Stichting-MINIX-Rese ... 386.s#L325
This save function is called by all the hardware interrupt handlers: https://github.com/Stichting-MINIX-Rese ... 386.s#L217
(The counterpart popad is found here: https://github.com/Stichting-MINIX-Rese ... 386.s#L401)
Re: register preservation considerations across syscalls
Further, support for 8086 segmentation was removed before 3.1 was released with the 3rd edition of OSDI.
Some of the history before then still exists in the converted git repository, though, and we can look at the 16-bit version of the interrupt handlers, where we find the general purpose registers being saved: https://github.com/Stichting-MINIX-Rese ... 35C20-L349
Some of the history before then still exists in the converted git repository, though, and we can look at the 16-bit version of the interrupt handlers, where we find the general purpose registers being saved: https://github.com/Stichting-MINIX-Rese ... 35C20-L349
-
- Member
- Posts: 5560
- Joined: Mon Mar 25, 2013 7:01 pm
Re: register preservation considerations across syscalls
Hardware interrupts may happen any time they're enabled, so any registers the interrupt handler may modify must be saved. Software interrupts occur only when requested, so no registers need to be saved.ITchimp wrote:what are the considerations for determining whether registers should be saved, and if so, which ones?
In practice, though, it's usually easier to save all registers when entering the interrupt handler. It simplifies things like debugging, where you might want to peek at the current state of an interrupted program, and it simplifies context switching since the program's entire context has already been saved. For software interrupts, it also removes the risk of leaking privileged data.
Re: register preservation considerations across syscalls
Uniformity in what exactly the stack frame looks like also allows syscalls to use the same register structure as the rest of the kernel, and it allows syscalls and interrupts to share the return code. Because it turns out in a UNIX based OS, that is where you can do a few things.Octocontrabass wrote:In practice, though, it's usually easier to save all registers when entering the interrupt handler. It simplifies things like debugging, where you might want to peek at the current state of an interrupted program, and it simplifies context switching since the program's entire context has already been saved. For software interrupts, it also removes the risk of leaking privileged data.
Carpe diem!