register preservation considerations across syscalls

Question about which tools to use, bugs, the best way to implement a function, etc should go here. Don't forget to see if your question is answered in the wiki first! When in doubt post here.
Post Reply
ITchimp
Member
Member
Posts: 134
Joined: Sat Aug 18, 2018 8:44 pm

register preservation considerations across syscalls

Post by ITchimp »

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?
klange
Member
Member
Posts: 679
Joined: Wed Mar 30, 2011 12:31 am
Libera.chat IRC: klange
Discord: klange

Re: register preservation considerations across syscalls

Post by klange »

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
ITchimp
Member
Member
Posts: 134
Joined: Sat Aug 18, 2018 8:44 pm

Re: register preservation considerations across syscalls

Post by ITchimp »

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
klange
Member
Member
Posts: 679
Joined: Wed Mar 30, 2011 12:31 am
Libera.chat IRC: klange
Discord: klange

Re: register preservation considerations across syscalls

Post by klange »

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)
klange
Member
Member
Posts: 679
Joined: Wed Mar 30, 2011 12:31 am
Libera.chat IRC: klange
Discord: klange

Re: register preservation considerations across syscalls

Post by klange »

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
Octocontrabass
Member
Member
Posts: 5501
Joined: Mon Mar 25, 2013 7:01 pm

Re: register preservation considerations across syscalls

Post by Octocontrabass »

ITchimp wrote:what are the considerations for determining whether registers should be saved, and if so, which ones?
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.

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.
nullplan
Member
Member
Posts: 1761
Joined: Wed Aug 30, 2017 8:24 am

Re: register preservation considerations across syscalls

Post by nullplan »

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.
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.
Carpe diem!
Post Reply