OSDev.org

The Place to Start for Operating System Developers
It is currently Sun Apr 28, 2024 12:35 am

All times are UTC - 6 hours




Post new topic Reply to topic  [ 7 posts ] 
Author Message
 Post subject: register preservation considerations across syscalls
PostPosted: Fri Nov 24, 2023 8:00 pm 
Offline
Member
Member

Joined: Sat Aug 18, 2018 8:44 pm
Posts: 127
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?


Top
 Profile  
 
 Post subject: Re: register preservation considerations across syscalls
PostPosted: Fri Nov 24, 2023 9:54 pm 
Offline
Member
Member

Joined: Wed Mar 30, 2011 12:31 am
Posts: 676
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

_________________
toaruos on github | toaruos.org | gitlab | twitter | bim - a text editor


Top
 Profile  
 
 Post subject: Re: register preservation considerations across syscalls
PostPosted: Sat Nov 25, 2023 2:22 am 
Offline
Member
Member

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


Top
 Profile  
 
 Post subject: Re: register preservation considerations across syscalls
PostPosted: Sat Nov 25, 2023 2:53 am 
Offline
Member
Member

Joined: Wed Mar 30, 2011 12:31 am
Posts: 676
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)

_________________
toaruos on github | toaruos.org | gitlab | twitter | bim - a text editor


Top
 Profile  
 
 Post subject: Re: register preservation considerations across syscalls
PostPosted: Sat Nov 25, 2023 3:07 am 
Offline
Member
Member

Joined: Wed Mar 30, 2011 12:31 am
Posts: 676
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

_________________
toaruos on github | toaruos.org | gitlab | twitter | bim - a text editor


Top
 Profile  
 
 Post subject: Re: register preservation considerations across syscalls
PostPosted: Sat Nov 25, 2023 3:06 pm 
Offline
Member
Member

Joined: Mon Mar 25, 2013 7:01 pm
Posts: 5146
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.


Top
 Profile  
 
 Post subject: Re: register preservation considerations across syscalls
PostPosted: Sat Nov 25, 2023 10:27 pm 
Offline
Member
Member

Joined: Wed Aug 30, 2017 8:24 am
Posts: 1605
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!


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 7 posts ] 

All times are UTC - 6 hours


Who is online

Users browsing this forum: Bing [Bot], Ringding and 32 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group