Get rid of %r8 linker stubs

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

The following is actually a long branch stub

Here's where rp is set.

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.

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   `------------------------

= Alan Modra <[email protected]> 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

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.

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.

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

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

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.