Setup_Frame

[cs412017]

I have been trying to debug my implementation of Setup_Frame for a while
now and have not been getting anywhere. I had a few questions that I
needed to get clarified.

1. There are 2 parameters passed to Setup_Frame, the thread that just
got context switched to and a copy of the original interrupt state for
the thread (when it got created). Is this right?

2. The user stack pointer is on the stack just below the passed in
interrupt state (not the interrupt state that is currently on the kernel
stack, pointed to by kthread->esp). Is this correct?

3. We have to push on the user stack (obtained from the user stack
pointer) the current interrupt state on the kernel stack, that is, the
64 bytes that are lying ahead of kthread->esp?

4. As far as getting the address of functions go, I am currently using
User_To_Kernel 3 times, once for each handler in Sys_RegDeliver, and
storing the return value in 3 signal handlers. Is this the right way to
get the address?
For the trampoline, I am just setting the address of this handler as
asked in the description on the user stack.

5. I think steps 2,3, and 4 are just so that we can recover the current
state of the frame (through Sys_ReturnSignal / Complete_Frame). Steps 1
and 5 are the steps that result in our signal handler being invoked, ie,
choosing the correct handler and then setting the program counter to
point to that handler. Is this right?
If this is the case, even if I should go wrong in steps 2,3,4 if I just
set the program counter (on the kernel stack) correctly, the signal
handler should be invoked...?

Answers to these questions would be appreciated.
Thanks.

[Saurabh Srivastava]

| 1. There are 2 parameters passed to Setup_Frame, the thread that just
| got context switched to and a copy of the original interrupt state for
| the thread (when it got created). Is this right?

that is true in part. it is actually the state which was there when it
was switched out. if this is first time that the process is getting the
cpu then yes, it would be the interrupt state which was initialized to
default values when the process was created.

| 2. The user stack pointer is on the stack just below the passed in
interrupt state

yes.

| 3. We have to push on the user stack (obtained from the user stack
| pointer) the current interrupt state on the kernel stack, that is, the
| 64 bytes that are lying ahead of kthread->esp?

the interrupt state is passed to you as the second parameter, the *esp.
You need to push that onto the user stack and this would be of size
sizeof(struct Interrupt_State) bytes.

| 4. As far as getting the address of functions go, I am currently using
| User_To_Kernel 3 times, once for each handler in Sys_RegDeliver, and
| storing the return value in 3 signal handlers. Is this the right way to
| get the address?
| For the trampoline, I am just setting the address of this handler as
| asked in the description on the user stack.

The functions are already in user space and this is where they will be
executed (when the cpu context switches to that process). Therefore just
store the passed addresses as is. similarly for the trampoline. you still
need to validate that it is valid user memory.

| 5. I think steps 2,3, and 4 are just so that we can recover the current
| state of the frame (through Sys_ReturnSignal / Complete_Frame). Steps 1
| and 5 are the steps that result in our signal handler being invoked, ie,
| choosing the correct handler and then setting the program counter to
| point to that handler. Is this right?
| If this is the case, even if I should go wrong in steps 2,3,4 if I just
| set the program counter (on the kernel stack) correctly, the signal
| handler should be invoked...?

yes, in part. but you will be tinkering around with the user stack and
handling that incorrectly will not be advisable. |