OSDev.org

The Place to Start for Operating System Developers
It is currently Thu Mar 28, 2024 6:42 pm

All times are UTC - 6 hours




Post new topic Reply to topic  [ 22 posts ]  Go to page Previous  1, 2
Author Message
 Post subject: Re: Help with very persistent scheduler bug
PostPosted: Sun Apr 30, 2017 9:29 am 
Offline
Member
Member

Joined: Fri Feb 10, 2017 8:25 am
Posts: 30
OK so I have created an ASM function "set_stack_ptr", (2 parameters: new stack ptr, and new instruction pointer) which is defined like this (nasm format, with Intel syntax):

Code:
global set_stack_ptr
set_stack_ptr:
   mov eax, [esp + 4]
   mov ebx, esp
   mov esp, eax

   push ebp   ; continue the linked list of ebp's

   mov eax, [esp + 8]   
   push eax      ; push second param for "ret" to work

   mov ecx, 4
loop_stack:
   mov edx, [ebx + 4*ecx]
   push edx
   dec ecx
loop_bottom:
   cmp ecx, 1
   jne loop_stack

   ret


the function changes esp, then pushes the old ebp to the new stack (which corresponds to the new ebp of this particular function), and then pushes eip to the new stack. After doing this, it copies the previous stack's values and pushes them into the new thread stack.

it is called from the scheduler function at the end (after the register restoring memcpy), like this:

Code:
   // set the registers from the current thread's saved state
   memcpy(r, &(thread_running->state_reg), sizeof(registers));   

   set_stack_ptr(r->esp, r->eip);
}


It "kind of" works, but gets stuck on the first thread. So my question is, what values do I need to push to the new stack so that the program can continue seamlessly through the esp transition?


Top
 Profile  
 
 Post subject: Re: Help with very persistent scheduler bug
PostPosted: Sun Apr 30, 2017 10:05 am 
Offline
Member
Member
User avatar

Joined: Thu Jul 12, 2012 7:29 am
Posts: 723
Location: Tallinn, Estonia
prasoc wrote:
Well the idea of the "run" variable in each thread is that when the scheduler starts (loops around the first time), it doesn't actually SAVE the registers until it's ran at least once - otherwise you would overwrite the thread's state with nonsense.


But the current thread's state is not nonsense - since it's already running it has some state that HAS to be saved to later return to.

_________________
Learn to read.


Top
 Profile  
 
 Post subject: Re: Help with very persistent scheduler bug
PostPosted: Sun Apr 30, 2017 10:11 am 
Offline
Member
Member
User avatar

Joined: Sat Jan 15, 2005 12:00 am
Posts: 8561
Location: At his keyboard!
Hi,

prasoc wrote:
It "kind of" works, but gets stuck on the first thread. So my question is, what values do I need to push to the new stack so that the program can continue seamlessly through the esp transition?


From the Wikipedia page; for the "cdecl" calling convention:

"Registers EAX, ECX, and EDX are caller-saved, and the rest are callee-saved. The x87 floating point registers ST0 to ST7 must be empty (popped or freed) when calling a new function, and ST1 to ST7 must be empty on exiting a function. ST0 must also be empty when not used for returning a value."

This translates to something like:

Code:
switch_to_task:
    mov eax, [esp + 4*1]      ;eax = address to store this task's ESP
    mov ecx, [esp + 4*2]      ;ecx = address to get next task's ESP

    ;Save general purpose registers for previous task
    ; Note: EAX, ECX, EDX and "return EIP" are saved by caller, so don't need to be saved again

    push ebx
    push esi
    push edi
    push ebp

    ;Save previous task's ESP

    mov [eax],esp

    ;Load next task's ESP

    mov esp,[ecx]

    ;Load general purpose registers for next task

    pop ebp
    pop edi
    pop esi
    pop ebx

    ;Return to next task's EIP

    ret


Of course this is just "bare minimum" - you'd add more later (e.g. worrying about FPU/MMX/SSE/AVX state, checking if CR3 needs to be changed and doing that, setting FS for thread local storage, etc).


Cheers,

Brendan

_________________
For all things; perfection is, and will always remain, impossible to achieve in practice. However; by striving for perfection we create things that are as perfect as practically possible. Let the pursuit of perfection be our guide.


Top
 Profile  
 
 Post subject: Re: Help with very persistent scheduler bug
PostPosted: Sun Apr 30, 2017 12:06 pm 
Offline
Member
Member

Joined: Fri Feb 10, 2017 8:25 am
Posts: 30
dozniak wrote:
prasoc wrote:
Well the idea of the "run" variable in each thread is that when the scheduler starts (loops around the first time), it doesn't actually SAVE the registers until it's ran at least once - otherwise you would overwrite the thread's state with nonsense.


But the current thread's state is not nonsense - since it's already running it has some state that HAS to be saved to later return to.



At the beginning it is, each thread needs to run atleast once before it has a proper state, so the scheduler goes like this:

>>>>> run 1: (do not save the current registers into task 0, as it hasnt ran yet)
(increment the task counter)
set task 1 "ran" = true
load task 1 into the register and run
-
>>>>> run 2: save task 1, because "ran = true"
(increment the task counter)
set task 2 "ran" = true
load task 2 into the register and run
-
>>>>> run 3: save task 2, because "ran = true"
(increment the task counter)
set task 3 "ran" = true
load task 3 into the register and run
-
etc. etc.

it pins down the edge case of the first loop not having a "previous state".

Brendan wrote:
This translates to something like:


Thank you for the example task switching code, Brendan. I will try and incorporate it into my scheduler and report back my success / failures :)


Top
 Profile  
 
 Post subject: Re: Help with very persistent scheduler bug
PostPosted: Tue May 02, 2017 2:10 pm 
Offline
Member
Member
User avatar

Joined: Thu Jul 12, 2012 7:29 am
Posts: 723
Location: Tallinn, Estonia
prasoc wrote:
dozniak wrote:
But the current thread's state is not nonsense - since it's already running it has some state that HAS to be saved to later return to.


At the beginning it is, each thread needs to run atleast once before it has a proper state, so the scheduler goes like this:


I tell you, it is not; because each thread must start the execution somewhere and this is it's initial state (stack and program counter at least).

_________________
Learn to read.


Top
 Profile  
 
 Post subject: Re: Help with very persistent scheduler bug
PostPosted: Wed May 03, 2017 11:04 am 
Offline
Member
Member

Joined: Fri Feb 10, 2017 8:25 am
Posts: 30
dozniak wrote:
prasoc wrote:
dozniak wrote:
But the current thread's state is not nonsense - since it's already running it has some state that HAS to be saved to later return to.


At the beginning it is, each thread needs to run atleast once before it has a proper state, so the scheduler goes like this:


I tell you, it is not; because each thread must start the execution somewhere and this is it's initial state (stack and program counter at least).


Sorry, I misrepresented what my code was doing - I do indeed setup the "beginning state" in the Thread constructor.

What I meant is, the first time "scheduler_next" is called, the previous state of execution corresponds to the kernel's setup function (my kmain function). This doesn't have a thread associated with it. So I need to wait for ONE task switch before I can save the registers.

-


I am getting close to solving the problems: ESP gets changed (thanks Brendan) and some values get pushed, just got to make sure the values needed upon the jmp command are actually on the stack!


Top
 Profile  
 
 Post subject: Re: Help with very persistent scheduler bug
PostPosted: Sat May 06, 2017 9:36 am 
Offline
Member
Member

Joined: Fri Feb 10, 2017 8:25 am
Posts: 30
Finally got it! :D

Brendan, your switch_to_task function gave me enough of the picture to understand how to switch the ESP (with the correct stack values) and finally crack the problem. The code I was using originally was waaaay too complicated for what I needed; I'm shocked at how simple the finished scheduler function is!

Thank you all for the help
prasoc


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 22 posts ]  Go to page Previous  1, 2

All times are UTC - 6 hours


Who is online

Users browsing this forum: Bing [Bot], Google [Bot] and 83 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