[parisc-linux] Panic on boot in 64 bit 2.6.6-rc1-pa0

[parisc-linux] Panic on boot in 64 bit 2.6.6-rc1-pa0

[James Bottomley]

I've traced this to an apparent linker fault.  It seems to be being
caused by having the scheduling function in its own section.

The offending code is in entry.S; this is what the code actually says:

syscall_do_resched:
        bl      schedule,%r2
#ifdef __LP64__
        ldo     -16(%r30),%r29          /* Reference param save area */
#else
        nop
#endif
        b       syscall_check_bh  /* if resched, we start over again */
        nop

And this is what it assembles to in the final vmlinux:

000000001010d05c <syscall_do_resched>:
    1010d05c:   e8 54 12 ac     b,l 101369b8 <dbl_to_sgl_fcnvxf+0xd0>,rp
    1010d060:   37 dd 3f e1     ldo -10(sp),ret1
    1010d064:   e8 1f 1b ed     b,l 1010ce60 <syscall_check_bh>,r0
    1010d068:   08 00 02 40     nop

Apparently ld has simply loaded an out of range value for the branch.  I
can't see that this is a global fault, otherwise calling init functions
wouldn't work either, but it does.

I've hacked a temporary work around in vmlinux.lds.S (simply make all of
the required functions close enough to entry.S that they don't need
stubs), but I'd really like some input from the toolchain people about
what the real problem actually is.

James

Index: arch/parisc/kernel/vmlinux.lds.S
===================================================================
RCS file: /var/cvs/linux-2.6/arch/parisc/kernel/vmlinux.lds.S,v
retrieving revision 1.10
diff -u -r1.10 vmlinux.lds.S
--- a/arch/parisc/kernel/vmlinux.lds.S	15 Apr 2004 18:04:14 -0000	1.10
+++ b/arch/parisc/kernel/vmlinux.lds.S	22 Apr 2004 22:30:16 -0000
@@ -49,8 +49,13 @@
 
   _text = .;			/* Text and read-only data */
   .text ALIGN(16) : {
-	*(.text*)
+	*(.text)
 	SCHED_TEXT
+	*(.text.do_softirq)
+	*(.text.sys_exit)
+	*(.text.do_sigaltstack)
+	*(.text.do_fork)
+	*(.text.*)
 	*(.PARISC.unwind)
 	*(.fixup)
 	*(.lock.text)		/* out-of-line lock text */

Re: [parisc-linux] Panic on boot in 64 bit 2.6.6-rc1-pa0

[John David Anglin]

> I've traced this to an apparent linker fault.  It seems to be being
> caused by having the scheduling function in its own section.
> 
> The offending code is in entry.S; this is what the code actually says:
> 
> syscall_do_resched:
>         bl      schedule,%r2
> #ifdef __LP64__
>         ldo     -16(%r30),%r29          /* Reference param save area */
> #else
>         nop
> #endif
>         b       syscall_check_bh  /* if resched, we start over again */
>         nop
> 
> And this is what it assembles to in the final vmlinux:
> 
> 000000001010d05c <syscall_do_resched>:
>     1010d05c:   e8 54 12 ac     b,l 101369b8 <dbl_to_sgl_fcnvxf+0xd0>,rp
>     1010d060:   37 dd 3f e1     ldo -10(sp),ret1
>     1010d064:   e8 1f 1b ed     b,l 1010ce60 <syscall_check_bh>,r0
>     1010d068:   08 00 02 40     nop
> 
> Apparently ld has simply loaded an out of range value for the branch.  I
> can't see that this is a global fault, otherwise calling init functions
> wouldn't work either, but it does.
> 
> I've hacked a temporary work around in vmlinux.lds.S (simply make all of
> the required functions close enough to entry.S that they don't need
> stubs), but I'd really like some input from the toolchain people about
> what the real problem actually is.

If schedule is too far away, the linker will add a long branch stub.
This apparently doesn't work in the kernel.  On the otherhand, `b,l'
should go about 8 MB without needing a stub.

Disassemble 101369b8 and see if it's a linker stub.

Dave
-- 
J. David Anglin                                  dave.anglin@nrc-cnrc.gc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6602)

Re: [parisc-linux] Panic on boot in 64 bit 2.6.6-rc1-pa0

[James Bottomley]

On Thu, 2004-04-22 at 18:50, John David Anglin wrote:
> If schedule is too far away, the linker will add a long branch stub.
> This apparently doesn't work in the kernel.  On the otherhand, `b,l'
> should go about 8 MB without needing a stub.

Well, but it does ... we have other jumps that seem to be correctly
stubbed.

> Disassemble 101369b8 and see if it's a linker stub.

I did; it's genuinely in the middle of the dbl_to_sgl_fcnvxf; no sign of
any stub code anywhere close.

James

Re: [parisc-linux] Panic on boot in 64 bit 2.6.6-rc1-pa0

[John David Anglin]

> On Thu, 2004-04-22 at 18:50, John David Anglin wrote:
> > If schedule is too far away, the linker will add a long branch stub.
> > This apparently doesn't work in the kernel.  On the otherhand, `b,l'
> > should go about 8 MB without needing a stub.
> 
> Well, but it does ... we have other jumps that seem to be correctly
> stubbed.

Looking at a couple ok 64-bit kernels, I'm surprised that stubs are
needed for "b,l x,%rp".  It suggests that these branches are getting
treated as 17-bit branches instead of 22-bit branches.  Of course,
"b" is limited to 17-bit displacements and it could easily need
a stub.

Which tool chain?

Dave
-- 
J. David Anglin                                  dave.anglin@nrc-cnrc.gc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6602)

Re: [parisc-linux] Panic on boot in 64 bit 2.6.6-rc1-pa0

[James Bottomley]

On Thu, 2004-04-22 at 19:13, John David Anglin wrote:
> Looking at a couple ok 64-bit kernels, I'm surprised that stubs are
> needed for "b,l x,%rp".  It suggests that these branches are getting
> treated as 17-bit branches instead of 22-bit branches.  Of course,
> "b" is limited to 17-bit displacements and it could easily need
> a stub.

Apparently, they are.  If you objdump the .o files, you see they're of
type R_PARISC_PCREL17F

> Which tool chain?

A fairly recent one:

2.14.90.0.7 20031029 Debian

James

Re: [parisc-linux] Panic on boot in 64 bit 2.6.6-rc1-pa0

[John David Anglin]

> Apparently, they are.  If you objdump the .o files, you see they're of
> type R_PARISC_PCREL17F

If you look at the .level directive in the assembler output for one of
these files, do you see "2.0w".  The branches should also appear as "b,l"
instead of the PA 1.x "bl".  This should tell us whether this is a gcc
or assembler problem.

Dave
-- 
J. David Anglin                                  dave.anglin@nrc-cnrc.gc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6602)

Re: [parisc-linux] Panic on boot in 64 bit 2.6.6-rc1-pa0

[James Bottomley]

On Fri, 2004-04-23 at 09:40, John David Anglin wrote:
> If you look at the .level directive in the assembler output for one of
> these files, do you see "2.0w".  The branches should also appear as "b,l"
> instead of the PA 1.x "bl".  This should tell us whether this is a gcc
> or assembler problem.

The file causing the problems is entry.S, so it's an assembler file, not
a gcc file.

It has a .level 2.0w (with the appropriate #ifdefs) at the top.

Now, if you look at an objdump of the .o, it shows:

000000000000205c <syscall_do_resched>:
    205c:	e8 40 00 00 	b,l 2064 <syscall_do_resched+0x8>,rp
			205c: R_PARISC_PCREL17F	schedule
    2060:	37 dd 3f e1 	ldo -10(sp),ret1
    2064:	e8 1f 1b ed 	b,l 1e60 <syscall_check_bh>,r0
    2068:	08 00 02 40 	nop

I suppose this means gas thinks it has to emit short relocations.

You have access to what I'm seeing; my kernel build environment is on
gsyprf11:~jejb/cvsnode/linux-2.6

James

Re: [parisc-linux] Panic on boot in 64 bit 2.6.6-rc1-pa0

[John David Anglin]

> It has a .level 2.0w (with the appropriate #ifdefs) at the top.

The .level 2.0w should come before any actual assembly code.  If the
includes define any assembly code this could be a problem.  The assembler
isn't very smart about changing levels.

> Now, if you look at an objdump of the .o, it shows:
> 
> 000000000000205c <syscall_do_resched>:
>     205c:	e8 40 00 00 	b,l 2064 <syscall_do_resched+0x8>,rp
> 			205c: R_PARISC_PCREL17F	schedule
>     2060:	37 dd 3f e1 	ldo -10(sp),ret1
>     2064:	e8 1f 1b ed 	b,l 1e60 <syscall_check_bh>,r0
>     2068:	08 00 02 40 	nop
> 
> I suppose this means gas thinks it has to emit short relocations.

Yes.  The code is using "bl".  It looks as if the assembler is
generating a 17-bit branch (sub-opcode 0) when it sees a "bl"
even when generating PA 2.0w code.  This would appear to be
wrong although I haven't checked what the HP assembler does.
Can you use "b,l" for PA 2.0 code?

Dave
-- 
J. David Anglin                                  dave.anglin@nrc-cnrc.gc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6602)

Re: [parisc-linux] Panic on boot in 64 bit 2.6.6-rc1-pa0

[James Bottomley]

On Fri, 2004-04-23 at 12:57, John David Anglin wrote:
> The .level 2.0w should come before any actual assembly code.  If the
> includes define any assembly code this could be a problem.  The assembler
> isn't very smart about changing levels.

Well, yes, there were (just macros, though).  However, I moved the level
setting right to the top of the file and it made no difference.

> Yes.  The code is using "bl".  It looks as if the assembler is
> generating a 17-bit branch (sub-opcode 0) when it sees a "bl"
> even when generating PA 2.0w code.  This would appear to be
> wrong although I haven't checked what the HP assembler does.
> Can you use "b,l" for PA 2.0 code?

Well, the 2.0 manual implies b,l can be used whether the execution is in
wide or narrow mode, so yes, it should apply to all 2.0 code.

James

Re: [parisc-linux] Panic on boot in 64 bit 2.6.6-rc1-pa0

[John David Anglin]

> > Can you use "b,l" for PA 2.0 code?
> 
> Well, the 2.0 manual implies b,l can be used whether the execution is in
> wide or narrow mode, so yes, it should apply to all 2.0 code.

Yes, that's what gcc generates for PA 2.0.

Regarding the assembler, I'm wondering if we want the keep "bl" for
generating 17-bit branches.  It's rather confusing and inconsistent
with the mnemonic mapping given in the 2.0 manual.  On the otherhand,
gas has been this way for 4-5 years.

Dave
-- 
J. David Anglin                                  dave.anglin@nrc-cnrc.gc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6602)

Re: [parisc-linux] Panic on boot in 64 bit 2.6.6-rc1-pa0

[James Bottomley]

On Fri, 2004-04-23 at 13:50, John David Anglin wrote:
> Yes, that's what gcc generates for PA 2.0.
> 
> Regarding the assembler, I'm wondering if we want the keep "bl" for
> generating 17-bit branches.  It's rather confusing and inconsistent
> with the mnemonic mapping given in the 2.0 manual.  On the otherhand,
> gas has been this way for 4-5 years.

Yes, I think our current pressing problem is to discover why hppa64-ld
is generating out of range PCREL17F branches instead of stubbing them. 
That's definitely what's causing the boot failure in 2.6.6-rc1-pa0.

It's so strange.  Since the init section is quite a way away, it should
already be stubbing jumps to the init section.  I can't work out why the
addition of yet another section (this time covering scheduler functions)
suddenly causes it to fail.

James

Re: [parisc-linux] Panic on boot in 64 bit 2.6.6-rc1-pa0

[John David Anglin]

> On Fri, 2004-04-23 at 13:50, John David Anglin wrote:
> > Yes, that's what gcc generates for PA 2.0.
> > 
> > Regarding the assembler, I'm wondering if we want the keep "bl" for
> > generating 17-bit branches.  It's rather confusing and inconsistent
> > with the mnemonic mapping given in the 2.0 manual.  On the otherhand,
> > gas has been this way for 4-5 years.
> 
> Yes, I think our current pressing problem is to discover why hppa64-ld
> is generating out of range PCREL17F branches instead of stubbing them. 
> That's definitely what's causing the boot failure in 2.6.6-rc1-pa0.
> 
> It's so strange.  Since the init section is quite a way away, it should
> already be stubbing jumps to the init section.  I can't work out why the
> addition of yet another section (this time covering scheduler functions)
> suddenly causes it to fail.

I think I know why.  The 64-bit linker only supports a single stub
table.  Things go bad when a branch can't reach its stub.  I hit this
when I was trying to implement tail calls.

Dave
-- 
J. David Anglin                                  dave.anglin@nrc-cnrc.gc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6602)

Re: [parisc-linux] Panic on boot in 64 bit 2.6.6-rc1-pa0

[James Bottomley]

On Fri, 2004-04-23 at 15:27, John David Anglin wrote:
> I think I know why.  The 64-bit linker only supports a single stub
> table.  Things go bad when a branch can't reach its stub.  I hit this
> when I was trying to implement tail calls.

That's a bit, um, unfortunate, given the current kernel predisposition
for adding a new section for almost every new feature...

How hard would it be to fix this?  Surely all we really need is one stub
table per text section in the final executable (linux still has only
about five executable sections in the vmlinux.lds.S map).

James

Re: [parisc-linux] Panic on boot in 64 bit 2.6.6-rc1-pa0

[John David Anglin]

> On Fri, 2004-04-23 at 15:27, John David Anglin wrote:
> > I think I know why.  The 64-bit linker only supports a single stub
> > table.  Things go bad when a branch can't reach its stub.  I hit this
> > when I was trying to implement tail calls.
> 
> That's a bit, um, unfortunate, given the current kernel predisposition
> for adding a new section for almost every new feature...
> 
> How hard would it be to fix this?  Surely all we really need is one stub
> table per text section in the final executable (linux still has only
> about five executable sections in the vmlinux.lds.S map).

I would guess a few days work, probably less if Alan Modra did it.
There's a model on how to do it in elf32-hppa.c.  Alan implemented
the 32-bit stub code.  It definitely should be done at some time.

Dave
-- 
J. David Anglin                                  dave.anglin@nrc-cnrc.gc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6602)