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.
iansjack wrote:I don't think you do. (or, rather, you have already done so by saving it on the stack when the interrupt was called.) I would say that if you are going to restore the registers within an interrupt then that is the point at which you wanted to have saved them. (I think Brendan misunderstood what you meant by "where" - he uses the stack, I use the task structure.)
I have an interrupt routine that switches tasks; it saves the current registers (in my case to the structure in memory) then restores the previously saved registers from the structure for the task to be switched to. As these were saved from within the task-switching interrupt routine, the stack of the new task will contain the correct entries to return from the interrupt. (It returns to a different place than the task switched from would, but that's what you want - you return to the point in the task's code where the interrupt to switch tasks was called from as if the task had been running all along.)
You do have to be careful that when you create a task you put the correct entries on its stack to pretend that it is in the middle of the interrupt routine, and "returns" to the start code for your task.
This is also extremely helpful. I need to seed my new thread stack with some values, so that it emulates the interrupt handler (and allows it to exit gracefully). I think this will finally allow me to have one-stack-per-thread
My experience is that problems with task switching can be some of the hardest bugs to track down. It's much easier when you have a relatively linear flow of code without context changes at unpredictable points. Once you grasp the concept that each task has it's own stack, and that interrupts and kernel code uses yet another stack (or stacks) thing get a bit clearer.
One tip (this is in 64-bit code - I'm not familiar with 32-bit code) is to use the facility to give an interrupt a particular stack, in particular for a page fault exception. Otherwise a relatively straightforward page fault quickly becomes a triple fault. Define a stack that you can guarantee will be good (nothing else touches it) and you don't have the problem of a page fault faulting again because of a corrupted stack. Obviously that's particularly important when you start treating a page fault exception as other than a terminal error.
My experience is that problems with task switching can be some of the hardest bugs to track down.
Yeah I've been having some issues with debugging non-linear flows (posted about it in an earlier thread) but I've *almost* got it. This stack issue will allow me to have a roughly working multithread system
is to use the facility to give an interrupt a particular stack, in particular for a page fault exception
Thats a really good idea, I haven't implemented exceptions yet, but being able to handle PF exceptions now will make my debugging life easier now and later on. I'm pretty pleased with my memory manager, it's pretty robust; I can now use that in many areas and be SURE that the issue isn't coming from the memory handler.
