Re: [parisc-linux] Get rid of %r8 linker stubs

Re: [parisc-linux] Get rid of %r8 linker stubs

[bame]

Unfortunately it looks like a couple of us are unable to build
working user-space executables with the no-%r8 linker.  I tried re-linking
with the old (16-June) one and that works (but of course that linker
can't link large executables).  So starting with:

	main(){}

I used both the 16-June and today's binutils.  It appears the "broken"
executable is running or sleeping (unlikely?) and it doesn't panic
the system.  I disassembled both versions and the _init sections are
a bit different, which isn't surprising, but also doesn't look right
to me.  Here's the one which works, using the old %r8 stub method:

000010b4 <_init>:
    10b4:       6b c2 3f d9     stw rp,-14(sr0,sp)
    10b8:       37 de 00 80     ldo 40(sp),sp
    10bc:       6b d3 3f c1     stw r19,-20(sr0,sp)
    10c0:       6b c4 3f 81     stw r4,-40(sr0,sp)
    /* jsr through stub to __gmon_start */
    10c4:       e5 00 22 f4     be,l 1178(sr4,r8),%sr0,%r31
    10c8:       08 13 02 44     copy r19,r4
    /* jsr through stub to __do_global_ctors_aux */
    10cc:       e5 00 22 bc     be,l 115c(sr4,r8),%sr0,%r31
    10d0:       08 00 02 40     nop
    10d4:       4b c2 3f 59     ldw -54(sr0,sp),rp
    10d8:       e8 40 c0 00     bv r0(rp)
    10dc:       4f c4 3f 81     ldw,mb -40(sr0,sp),r4

And here's the new one which fails.  Looks like maybe the %rp is
not being set, or the linker's overwriting a branch in a funny
way or something:

000010bc <_init>:
    10bc:       6b c2 3f d9     stw rp,-14(sr0,sp)
    10c0:       37 de 00 80     ldo 40(sp),sp
    10c4:       6b d3 3f c1     stw r19,-20(sr0,sp)
    10c8:       6b c4 3f 81     stw r4,-40(sr0,sp)
    /* jsr through local stub to __gmon_start */
    10cc:       e8 5f 1f c5     b,l 10b4 <_init-0x8>,rp
    10d0:       08 13 02 44     copy r19,r4
    /* branch to __do_global_ctors_aux !!! rp was never set !!! */
    10d4:       20 2b 40 00     ldil 56000,r1
    10d8:       e0 20 26 ba     be,n 35c(sr4,r1)
    /* nullified instruction -- otherwise it'd be an infinite loop */
    10dc:       e8 5f 1f e5     b,l 10d4 <_init+0x18>,rp
    10e0:       08 00 02 40     nop
    10e4:       4b c2 3f 59     ldw -54(sr0,sp),rp
    10e8:       e8 40 c0 00     bv r0(rp)
    10ec:       4f c4 3f 81     ldw,mb -40(sr0,sp),r4

Help?

	-Paul Bame

Re: [parisc-linux] Get rid of %r8 linker stubs

[Alan Modra]

On Tue, 4 Jul 2000 bame@riverrock.org wrote:

> And here's the new one which fails.  Looks like maybe the %rp is
> not being set, or the linker's overwriting a branch in a funny
> way or something:
> 
> 000010bc <_init>:
>     10bc:       6b c2 3f d9     stw rp,-14(sr0,sp)
>     10c0:       37 de 00 80     ldo 40(sp),sp
>     10c4:       6b d3 3f c1     stw r19,-20(sr0,sp)
>     10c8:       6b c4 3f 81     stw r4,-40(sr0,sp)
>     /* jsr through local stub to __gmon_start */
>     10cc:       e8 5f 1f c5     b,l 10b4 <_init-0x8>,rp
>     10d0:       08 13 02 44     copy r19,r4

The following is actually a long branch stub
>     /* branch to __do_global_ctors_aux !!! rp was never set !!! */
>     10d4:       20 2b 40 00     ldil 56000,r1
>     10d8:       e0 20 26 ba     be,n 35c(sr4,r1)

Here's where rp is set.
>     /* nullified instruction -- otherwise it'd be an infinite loop */
>     10dc:       e8 5f 1f e5     b,l 10d4 <_init+0x18>,rp
>     10e0:       08 00 02 40     nop
>     10e4:       4b c2 3f 59     ldw -54(sr0,sp),rp
>     10e8:       e8 40 c0 00     bv r0(rp)
>     10ec:       4f c4 3f 81     ldw,mb -40(sr0,sp),r4

The trouble is that _init is a single function that's been split in two
(see glibc/csu/Makefile crti,crtn), thus the linker thinks it's quite OK
to insert a stub at the start of the second section.  I'll have to do
something special with the .init section to work around this problem.

Alan Modra
-- 
Linuxcare.  Support for the Revolution.

Re: [parisc-linux] Get rid of %r8 linker stubs

[Ulrich Drepper]

Alan Modra <alan@linuxcare.com.au> writes:

> The trouble is that _init is a single function that's been split in two
> (see glibc/csu/Makefile crti,crtn), thus the linker thinks it's quite OK
> to insert a stub at the start of the second section.  I'll have to do
> something special with the .init section to work around this problem.

Simply create an appropriate initfini.c file for HP/UX.  Look in the
current glibc sources and you'll see that we already do this for SH.

-- 
---------------.                          ,-.   1325 Chesapeake Terrace
Ulrich Drepper  \    ,-------------------'   \  Sunnyvale, CA 94089 USA
Red Hat          `--' drepper at redhat.com   `------------------------

Re: [parisc-linux] Get rid of %r8 linker stubs

[bame]

= Alan Modra <alan@linuxcare.com.au> writes:
= 
= > The trouble is that _init is a single function that's been split in two
= > (see glibc/csu/Makefile crti,crtn), thus the linker thinks it's quite OK
= > to insert a stub at the start of the second section.  I'll have to do
= > something special with the .init section to work around this problem.
= 
= Simply create an appropriate initfini.c file for HP/UX.  Look in the
= current glibc sources and you'll see that we already do this for SH.

I don't think that'll work, because the parisc linker thinks it's allowed
to insert stubs in between separately-loaded things like functions.  The
use of .init from multiple .o files looks to the linker just like the
use of .text from multiple .o files.  I'd say there's a good chance the
linker might insert stubs *between* individual .init entries too (not
to mention .fini, and in general users can probably create arbitrary
segments to act similarly).

So unless we get to change how .init works (ugly hacks to gas perhaps?
I hope not) I think a special case in the linker is required.  I just
hope there's some sort of attribute on these magic kludge segments which
the linker can use rather than hard-coding the names or something.

Hopefully someone else has a better idea.

	-Paul Bame

Re: [parisc-linux] Get rid of %r8 linker stubs

[Alan Modra]

On Tue, 4 Jul 2000 bame@riverrock.org wrote:

> So unless we get to change how .init works (ugly hacks to gas perhaps?
> I hope not) I think a special case in the linker is required.  I just
> hope there's some sort of attribute on these magic kludge segments which
> the linker can use rather than hard-coding the names or something.

The linker patch I just checked in to puffin cvs is of the "magic
kludge" variety.  ie. Input sections named .init* and .fini* are handled
specially.  A more general approach would be to group stubs by output
section, at least for output sections that are small enough to be sure
that the stubs can be reached.  The extra work to do this isn't that
difficult - but it's a bit more than my quick fix.

Regards, Alan Modra
-- 
Linuxcare.  Support for the Revolution.

Re: [parisc-linux] Get rid of %r8 linker stubs

[Alan Modra]

On 4 Jul 2000, Ulrich Drepper wrote:

> Alan Modra <alan@linuxcare.com.au> writes:
> 
> > The trouble is that _init is a single function that's been split in two
> > (see glibc/csu/Makefile crti,crtn), thus the linker thinks it's quite OK
> > to insert a stub at the start of the second section.  I'll have to do
> > something special with the .init section to work around this problem.
> 
> Simply create an appropriate initfini.c file for HP/UX.  Look in the
> current glibc sources and you'll see that we already do this for SH.

Thanks for the hint.  It's probably a good idea.  Meanwhile, I've already
fixed the linker :)

Regards, Alan Modra
-- 
Linuxcare.  Support for the Revolution.

Re: [parisc-linux] Get rid of %r8 linker stubs

[bame]

Success!!!

I just natively compiled and ran hello-world on a 712!!!  
I had to add milli.o by hand but that's not a difficult thing to fix.

	-P

Re: [parisc-linux] Get rid of %r8 linker stubs

[Patric Karlstrom]

Hello,

Just wanted to check if there exists a bootfloppy? I have a 715 without a harddrive and i want to be able to boot and then mount my rootfilesystem with nfs.

Regards
Patric Karlstrom

Re: [parisc-linux] Get rid of %r8 linker stubs

[willy]

On Wed, Jul 05, 2000 at 08:43:25AM +0200, Patric Karlstrom wrote:
> 
> Hello,
> 
> Just wanted to check if there exists a bootfloppy? I have a 715 without
> a harddrive and i want to be able to boot and then mount my rootfilesystem
> with nfs.

that already works fine.  edit the palo makefile to specify your NFS server
and you're away.

-- 
The Sex Pistols were revolutionaries.  The Bay City Rollers weren't.

[parisc-linux] Get rid of %r8 linker stubs

[Alan Modra]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 1292 bytes --]

Hello all,
   The attached patch to puffin.external.hp.com CVS binutils-2.10
implements a new linker stub scheme for elf32-hppa.  (Well, it's new for
gnu - I believe the hp linker does something like this).

The new scheme works like this:  For any linker input section that needs a
stub to reach called routines, the linker creates a stub section located
immediately prior to the input section.  A call is simply redirected to
the stub, which consists of a long branch
  ldil LR'XXX,%r1
  be,n RR'XXX(%sr4,%r1)
to the destination.

The old scheme had a single stub section, and out-of-range calls changed
the call instruction from "b,l faraway,%r2" to "be,l stub(%sr4,%r8)".
This of course dedicates a register to point to the stubs, and has some
serious problems caused by changing the return pointer from the normal %r2
to the implicit %r31 used by "be,l".  Additionally, when we finally
implement elf32-hppa shared libraries, there are going to be a _lot_ more
stubs.  We may even exceed the maximum 256k of stubs, especially if we try
to combine .plt and .got with stubs to get a register back.

Anyway, I'd appreciate some brave souls testing out this patch.  A few
positive reports and I'll check the lot in to pehc.

Regards, Alan Modra
-- 
Linuxcare.  Support for the Revolution.




[-- Attachment #2: Type: APPLICATION/octet-stream, Size: 20092 bytes --]

Re: [parisc-linux] Get rid of %r8 linker stubs

[Paul Bame]

= 
= Hello all,
=    The attached patch to puffin.external.hp.com CVS binutils-2.10
= implements a new linker stub scheme for elf32-hppa.  (Well, it's new for
= gnu - I believe the hp linker does something like this).
= 
= The new scheme works like this:  For any linker input section that needs a
= stub to reach called routines, the linker creates a stub section located
= immediately prior to the input section.  A call is simply redirected to
= the stub, which consists of a long branch
=   ldil LR'XXX,%r1
=   be,n RR'XXX(%sr4,%r1)
= to the destination.
= 
= The old scheme had a single stub section, and out-of-range calls changed
= the call instruction from "b,l faraway,%r2" to "be,l stub(%sr4,%r8)".
= This of course dedicates a register to point to the stubs, and has some
= serious problems caused by changing the return pointer from the normal %r2
= to the implicit %r31 used by "be,l".  Additionally, when we finally
= implement elf32-hppa shared libraries, there are going to be a _lot_ more
= stubs.  We may even exceed the maximum 256k of stubs, especially if we try
= to combine .plt and .got with stubs to get a register back.
= 
= Anyway, I'd appreciate some brave souls testing out this patch.  A few
= positive reports and I'll check the lot in to pehc.

Well the good news is I can (with some trouble) link a native
binutils.  The bad news is that the kernel won't link.  To wit -

hppa1.1-linux-ld: fs/fs.o: cannot reach stub 080e89b4_00000000_printk
hppa1.1-linux-ld: fs/fs.o: cannot handle relocation R_PARISC_PCREL17F for printk at 0x3fc98 in .text

This follows a 'make clean'.  I only re-built the new binutils and not
gcc, if that matters.

	-P

Re: [parisc-linux] Get rid of %r8 linker stubs

[Jeffrey A Law]

  > = Hello all,
  > =    The attached patch to puffin.external.hp.com CVS binutils-2.10
  > = implements a new linker stub scheme for elf32-hppa.  (Well, it's new for
  > = gnu - I believe the hp linker does something like this).
  > = 
  > = The new scheme works like this:  For any linker input section that needs 
  > a
  > = stub to reach called routines, the linker creates a stub section located
  > = immediately prior to the input section.  A call is simply redirected to
  > = the stub, which consists of a long branch
  > =   ldil LR'XXX,%r1
  > =   be,n RR'XXX(%sr4,%r1)
  > = to the destination.
An FYI -- this is precisely the kind of scheme that I've wanted to see
for the GNU PA tools.

I'd like to get this code integrated into the official binutils releases.

  > = to the implicit %r31 used by "be,l".  Additionally, when we finally
  > = implement elf32-hppa shared libraries, there are going to be a _lot_ more
  > = stubs.  We may even exceed the maximum 256k of stubs, especially if we tr
  > = to combine .plt and .got with stubs to get a register back.
Not only that, the old scheme was not relocatable since it assumed all the
stubs sat in the first 256k of the address space .

jeff

Re: [parisc-linux] Get rid of %r8 linker stubs

[Alan Modra]

Hi Paul,
   Thanks for testing this out for me.  Did you have any success stories
to report with the latest binutils patch?  eg. Does tar still run?

On Thu, 22 Jun 2000, Paul Bame wrote:

> Well the good news is I can (with some trouble) link a native
> binutils.  The bad news is that the kernel won't link.  To wit -
> 
> hppa1.1-linux-ld: fs/fs.o: cannot reach stub 080e89b4_00000000_printk
> hppa1.1-linux-ld: fs/fs.o: cannot handle relocation R_PARISC_PCREL17F for printk at 0x3fc98 in .text
> 
> This follows a 'make clean'.  I only re-built the new binutils and not
> gcc, if that matters.

No, gcc doesn't need to be rebuilt.  The problem here (I think - I'm going
to build a kernel in a the moment) is the silly use of "ld -r" in the
kernel build process.  This has the unfortunate effect of concatenating
all the .text sections, making some too large for a branch to reach its
stub section.  Of course this same thing can happen with very large object
files.

One fairly simple work-around is to use -ffunction-sections when compiling,
as then you need a truely enormous function (> 4*2**(17-1) bytes long)
before you'll get "cannot reach stub"  Also, gcc has support for handling
even these enormous functions.

Regards, Alan Modra
-- 
Linuxcare.  Support for the Revolution.

Re: [parisc-linux] Get rid of %r8 linker stubs

[Alan Modra]

Hi Paul,
   I nearly forgot to follow up with the results of my kernel build.  It
was "ld -r" that caused the failure, and the following patch to the kernel
Makefile cures the build problem for me.  Not tested as I don't have any
hp hardware.

Regards, Alan
-- 
Linuxcare.  Support for the Revolution.

Index: Makefile
===================================================================
RCS file: /home/cvs/parisc/linux-2.3/Makefile,v
retrieving revision 1.17
diff -u -p -r1.17 Makefile
--- Makefile	2000/05/31 18:50:18	1.17
+++ Makefile	2000/06/23 10:11:16
@@ -95,6 +95,11 @@ AFLAGS := -D__ASSEMBLY__ $(CPPFLAGS)
 # use '-fno-strict-aliasing', but only if the compiler can take it
 CFLAGS += $(shell if $(CC) -fno-strict-aliasing -S -o /dev/null -xc /dev/null >/dev/null 2>&1; then echo "-fno-strict-aliasing"; fi)
 
+# Same for -ffunction-sections
+# This is needed for the new binutils as otherwise "ld -r" results in .text
+# sections that are too big (> 0x40000) for branches to reach stubs.
+CFLAGS += $(shell if $(CC) -ffunction-sections -S -o /dev/null -xc /dev/null >/dev/null 2>&1; then echo "-ffunction-sections"; fi)
+
 export	CPPFLAGS CFLAGS AFLAGS
 
 #

Re: [parisc-linux] Get rid of %r8 linker stubs

[willy]

On Fri, Jun 23, 2000 at 08:34:43PM +1000, Alan Modra wrote:
> Hi Paul,
>    I nearly forgot to follow up with the results of my kernel build.  It
> was "ld -r" that caused the failure, and the following patch to the kernel
> Makefile cures the build problem for me.  Not tested as I don't have any
> hp hardware.

Applying that patch to the kernel makefile and the r8-patch to the current
CVS binutils-2.10 yields a working kernel.  Thanks, Alan.

-- 
The Sex Pistols were revolutionaries.  The Bay City Rollers weren't.

Re: [parisc-linux] Get rid of %r8 linker stubs

[willy]

On Fri, Jun 23, 2000 at 11:45:16AM +1000, Alan Modra wrote:
> No, gcc doesn't need to be rebuilt.  The problem here (I think - I'm going
> to build a kernel in a the moment) is the silly use of "ld -r" in the
> kernel build process.  This has the unfortunate effect of concatenating
> all the .text sections, making some too large for a branch to reach its
> stub section.  Of course this same thing can happen with very large object
> files.
> 
> One fairly simple work-around is to use -ffunction-sections when compiling,
> as then you need a truely enormous function (> 4*2**(17-1) bytes long)
> before you'll get "cannot reach stub"  Also, gcc has support for handling
> even these enormous functions.

how about 
  --split-by-reloc COUNT      Split output sections every COUNT relocs
would that help?

-- 
The Sex Pistols were revolutionaries.  The Bay City Rollers weren't.

Re: [parisc-linux] Get rid of %r8 linker stubs

[Alan Modra]

On Tue, 4 Jul 2000 willy@thepuffingroup.com wrote:

> On Fri, Jun 23, 2000 at 11:45:16AM +1000, Alan Modra wrote:
> > One fairly simple work-around is to use -ffunction-sections when compiling,
> > as then you need a truely enormous function (> 4*2**(17-1) bytes long)
> > before you'll get "cannot reach stub"  Also, gcc has support for handling
> > even these enormous functions.
> 
> how about 
>   --split-by-reloc COUNT      Split output sections every COUNT relocs
> would that help?

No.  It would lead to the same problem as seen with the .init section.

-- 
Linuxcare.  Support for the Revolution.