All of lore.kernel.org
 help / color / mirror / Atom feed
From: Paul Bame <bame@fc.hp.com>
To: Alan Modra <alan@linuxcare.com.au>
Cc: parisc-linux@thepuffingroup.com
Subject: Re: [parisc-linux] Get rid of %r8 linker stubs
Date: Thu, 22 Jun 2000 14:33:09 -0600	[thread overview]
Message-ID: <E135Dev-0007ho-00@noam.fc.hp.com> (raw)
In-Reply-To: Your message of "Thu, 22 Jun 2000 00:07:14 +1000." <Pine.LNX.4.21.0006212254430.19417-101000@front.linuxcare.com.au>

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

  reply	other threads:[~2000-06-22 20:30 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2000-06-21 14:07 [parisc-linux] Get rid of %r8 linker stubs Alan Modra
2000-06-22 20:33 ` Paul Bame [this message]
2000-06-22 20:35   ` Jeffrey A Law
2000-06-23  1:45   ` Alan Modra
2000-06-23 10:34     ` Alan Modra
2000-07-03 19:15       ` willy
2000-07-04 14:21     ` willy
2000-07-05  0:38       ` Alan Modra
  -- strict thread matches above, loose matches on Subject: below --
2000-07-04 22:33 bame
2000-07-05  0:36 ` Alan Modra
2000-07-05  0:57   ` Ulrich Drepper
2000-07-05  1:52     ` bame
2000-07-05  2:38       ` Alan Modra
2000-07-05  1:55     ` Alan Modra
2000-07-05  2:58   ` bame
2000-07-05  6:43     ` Patric Karlstrom
2000-07-05  6:26       ` willy

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=E135Dev-0007ho-00@noam.fc.hp.com \
    --to=bame@fc.hp.com \
    --cc=alan@linuxcare.com.au \
    --cc=parisc-linux@thepuffingroup.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.