ABI defined register usage within function calls

[Scott Wood]

On 07/10/2013 08:54:39 AM, JiveTalkin wrote:
> Hello.
> 
> I would like to monitor the value of one of the parameters (within  
> the stack
> frame) that have been passed as part of a context switch (from process
> context to interrupt context).

I don't understand this...  What specifically do you mean by "interrupt  
context"?  Do you mean syscall context?  Syscall parameters are passed  
in registers, not in the stack frame.

> START_EXCEPTION does nothing more than align us to a word (32bit)  
> boundary
> (obviously for performance reasons). What I need to understand is the
> NORMAL_EXCEPTION_PROLOG. I reproduce it here:
> 
> 
> First thing it does it saves r10, r11 and r1(containing the Stack  
> pointer)
> into the scratch registers 0,1 and 2 respectively. Correct me if I am  
> wrong,
> but as per the older EABI, isn't it recommended for the OS to load  
> SPRG0
> with the start address of an area of memory (the stack top) to be  
> used by
> the 1st level interrupt handler? Or can these registers be used  
> anyway we
> see fit?

Linux doesn't use EABI -- and in any case, I don't see "SPRG" anywhere  
in the EABI document, and no relevant mention in the SVR4 ABI.  It's up  
to the OS how SPRGs are used.

> Moving on, it seems the kernel folks have decided to use SPRNG3 to  
> point to
> the currently running process's thread_struct structure. Is there a  
> document
> which recommends so or was it an unanimous decision taken during early
> development? Just curios.
> 
> Then we go on to check the value of the PR bit from the MSR which has  
> been
> copied by the hardware to SRR1. So here we are actually checking  
> whether the
> exception occurred when the machine was in user space or kernel space  
> right?
> 
> So once we determine that we've originated in the userspace, as is  
> the case
> for SystemCall, we are apparently updating r1 (stack pointer) with  
> (r1 +
> THREAD) - THREAD_INFO. Or is it actually r1 + (THREAD_INFO-THREAD)?

Neither; it's the address stored at r10 + (THREAD_INFO-THREAD).

> In
> either case, how does this take us to the top of the kernel stack, is
> something I am unable to get my head around. May be I do not know  
> some basic
> concepts here, which is why this is looking strange to me. Could  
> someone
> please elaborate? Some ASCII art would be really nice here.

r10 was loaded from SPRG3, and thus points to the thread struct.  The  
thread struct (a.k.a. SPRG3, a.k.a. THREAD) and a pointer to the stack  
are both contained within the task_struct (a.k.a. current).  At the  
bottom of the stack is the thread_info struct, which is why  
current->stack is called THREAD_INFO in asm-offsets.c.  Since THREAD  
and THREAD_INFO are both in the same struct, we can get THREAD_INFO by  
adding the difference in offsets to the THREAD pointer that we got from  
SPRG3.

That gets us to the bottom of the stack; ALLOC_STACK_FRAME() adds the  
size of the stack so that we point to the top and are ready to create a  
frame.  It's a confusing name since it doesn't actually allocate a  
frame; that happens in the "subi" instruction that follows.

> We then allocate an exception frame to hold the activation record  
> (stack
> frame) for the caller. Into this frame, we save the CR. We also save  
> R12 and
> R9 (as they are volatile registers and the caller must save them  
> before
> calling a function). We then retrieve the earlier stored values of  
> r10 and
> r11 and store them into the frame (using r11 as an anchor as it now  
> points
> to the top of the stack frame). Then we store the link register.
> 
> We retrieve previously stored r1 (previous frame's stack pointer  
> isn't it?),
> retrieve SRR0 (which includes the return address and in this case, the
> address of the next instruction in case of a syscall from userspace,
> correct?). If we have already stored the previous value of R1 then  
> what are
> we doing with this:
> 
> 
> 

What are we doing with what?

The previous value of r1 is still in r1.  At this point r11 holds the  
new stack pointer.  Did you misread the "stw r1, GPR1(r11)" as a load?

-Scott