[parisc-linux] Re: schedule_tail

[parisc-linux] Re: schedule_tail

[Matthew Wilcox]

On Thu, Feb 22, 2001 at 04:32:51PM +1100, Alan Modra wrote:
> On Thu, 22 Feb 2001, Helge Deller wrote:
> 
> > As far as I've tested, the following patch (HACK!) to 
> > ret_from_kernel_thread() against CVS head gets me at least to the 
> > init-process (where it then crashes).
> 
> I ripped out this call to schedule_tail _and_ the other one in
> child_return, and things are working again for me.  schedule_tail doesn't
> do much on uniprocessor.  Most likely %r26 was wrong.  I'd like to know 
> why the stack adjust before calling schedule_tail too.

It does a lot of important stuff on SMP though.  It does the stack adjust
before calling because the disassembled 32-bit SMP code looks like this:

101186f4 <schedule_tail>:
101186f4:       08 03 02 41     copy r3,r1
101186f8:       08 1e 02 43     copy sp,r3
101186fc:       6b c2 3f d9     stw rp,-14(sr0,sp)

and we don't want to trash what was below the sp.

-- 
Revolutions do not require corporate support.

Re: [parisc-linux] Re: schedule_tail

[Alan Modra]

On Wed, 21 Feb 2001, Matthew Wilcox wrote:

> It does a lot of important stuff on SMP though.

I'm not denying that :)

>  It does the stack adjust
> before calling because the disassembled 32-bit SMP code looks like this:
> 101186f4 <schedule_tail>:
> 101186f4:       08 03 02 41     copy r3,r1
> 101186f8:       08 1e 02 43     copy sp,r3
> 101186fc:       6b c2 3f d9     stw rp,-14(sr0,sp)
> 
> and we don't want to trash what was below the sp.

But this location is allowed to be modified by the callee, and I think you
already have a stack frame.

I wrote up some stuff on stack frames at
http://lists.parisc-linux.org/pipermail/parisc-linux/2001-February/011715.html

Alan

Re: [parisc-linux] Re: schedule_tail

[Alan Modra]

On Thu, 22 Feb 2001, Alan Modra wrote:

> I wrote up some stuff on stack frames at
> http://lists.parisc-linux.org/pipermail/parisc-linux/2001-February/011715.html

Which in looking at again, I realise is wrong.  :-(

The 64 bit "Outgoing Register Parameter Area" has eight entries, not four,
and the "Outgoing Stack Parameter Area" starts with arg word 8.

Re: [parisc-linux] Re: schedule_tail

[Matthew Wilcox]

On Thu, Feb 22, 2001 at 05:21:49PM +1100, Alan Modra wrote:
> But this location is allowed to be modified by the callee, and I think you
> already have a stack frame.

Umm... I'm not sure we always do.  It shouldn't be hard to arrange though.

> I wrote up some stuff on stack frames at
> http://lists.parisc-linux.org/pipermail/parisc-linux/2001-February/011715.html

thanks, i was going from the pdfs, but yours is easier to understand.
i don't quite see why it needs `ap' (%r29) to be assigned a value when
calling a function which has no arguments.

would a `call-c-function' macro make sense?

-- 
Revolutions do not require corporate support.

Re: [parisc-linux] Re: schedule_tail

[Alan Modra]

On Wed, 21 Feb 2001, Matthew Wilcox wrote:

> On Thu, Feb 22, 2001 at 05:21:49PM +1100, Alan Modra wrote:
> > But this location is allowed to be modified by the callee, and I think you
> > already have a stack frame.
> 
> Umm... I'm not sure we always do.  It shouldn't be hard to arrange though.
> 
> > I wrote up some stuff on stack frames at
> > http://lists.parisc-linux.org/pipermail/parisc-linux/2001-February/011715.html
> 
> thanks, i was going from the pdfs, but yours is easier to understand.
> i don't quite see why it needs `ap' (%r29) to be assigned a value when
> calling a function which has no arguments.

No, it shouldn't be needed in that case.  It may be necessary in any of
the following cases:
a) the called function takes the address of one of it's args
b) has variable arguments
c) has more than 8 words of args (not always the same as more than 8 args)
d) needs to spill one of its args to the stack.
gcc ought to be able to convert a reference via %r29 to one via %r30, but
that doesn't work at the moment.

> would a `call-c-function' macro make sense?

Yes.

Re: [parisc-linux] Re: schedule_tail

[Alan Modra]

On Thu, 22 Feb 2001, Alan Modra wrote:

> First time in do_fork, I see
>  p = 0x14ff0000, current = 0x102cc000 (= init_task)
> 
> first call to ret_from_kernel_thread gives
>  r26 = 0x102cc000, r30 = 0x14ff0500, and called func = init
> 
> so that checks out OK.  Disassmbling schedule_tail doesn't show anything
> bad.
> 
>  copy r3,r1
>  copy sp,r3
>  stw,ma r1,0x40(sp)
>  ldw 0x28(r26),r19
>  depwi 0,27,1,r19
>  stw r19,0x28(r26)
>  ldo 0x40(r3),sp
>  bv (rp)
>  ldw,mb -0x40(sp),r3

This is really crazy (or I am).  I replaced the calls to schedule_tail
with a call to foo_schedule_tail, a local copy of the above without the
bit twiddling.  Still crashed.  OK, so maybe the stack is messed up.
Turn foo_schedule_tail into

foo_schedule_tail:
  bv (%rp)
  nop

It crashes!!  Remove the calls, and it's OK.  What????

Re: [parisc-linux] Re: schedule_tail

[Richard Hirst]

On Fri, Feb 23, 2001 at 01:28:36AM +1100, Alan Modra wrote:
> This is really crazy (or I am).  I replaced the calls to schedule_tail

This helps for me.  b,l disassembles as call, not b,l ...,rp:

===================================================================
RCS file: /home/cvs/parisc/linux/arch/parisc/kernel/entry.S,v
retrieving revision 1.72
diff -u -r1.72 entry.S
--- entry.S     2001/02/20 02:19:52     1.72
+++ entry.S     2001/02/22 14:33:43
@@ -509,7 +509,7 @@
 
        /* Call schedule_tail first though */
 
-       b,l     schedule_tail, %r2
+       bl      schedule_tail, %r2
        ldo     64(%r30), %r30
 
        ldo     -64(%r30), %r30
@@ -1790,7 +1790,7 @@
 
        /* Set the return value for the child */
 child_return:
-       b,l     schedule_tail, %r2
+       bl      schedule_tail, %r2
        ldo     64(%r30), %r30
 
        ldo     -64(%r30), %r30


Richard

Re: [parisc-linux] Re: schedule_tail

[Matthew Wilcox]

On Thu, Feb 22, 2001 at 02:43:31PM +0000, Richard Hirst wrote:
> On Fri, Feb 23, 2001 at 01:28:36AM +1100, Alan Modra wrote:
> > This is really crazy (or I am).  I replaced the calls to schedule_tail
> 
> This helps for me.  b,l disassembles as call, not b,l ...,rp:
> 
> ===================================================================
> RCS file: /home/cvs/parisc/linux/arch/parisc/kernel/entry.S,v
> retrieving revision 1.72
> diff -u -r1.72 entry.S
> --- entry.S     2001/02/20 02:19:52     1.72
> +++ entry.S     2001/02/22 14:33:43
> @@ -509,7 +509,7 @@
>  
>         /* Call schedule_tail first though */
>  
> -       b,l     schedule_tail, %r2
> +       bl      schedule_tail, %r2

This is crazy.  entry.S is .level 2.0.  bl is not a pa2.0 opcode, b,l is!
What is going on?!

Wait.  Is it...

`The word displacement is assembled from the w, w1, w2, and (when the
,L completer is specified with GR 2 as the link register) w3 fields in
the instruction.''

which, iirc is not available on pa1.1 processors.  So here's the crucial
difference.  Not 32-bit vs 64-bit.  Not SMP vs UP.  But pa1.1 vs 2.0.

-- 
Revolutions do not require corporate support.