From: "H . J . Lu" <hjl@lucon.org>
To: Alan Modra <alan@linuxcare.com.au>
Cc: libc-alpha@sources.redhat.com, parisc-linux@thepuffingroup.com,
parisc@lists.linuxcare.com
Subject: Re: hppa glibc ld -r
Date: Thu, 17 Aug 2000 08:23:08 -0700 [thread overview]
Message-ID: <20000817082308.B20071@lucon.org> (raw)
In-Reply-To: <Pine.LNX.4.21.0008171700460.28670-100000@front.linuxcare.com.au>; from alan@linuxcare.com.au on Thu, Aug 17, 2000 at 05:59:48PM +1000
On Thu, Aug 17, 2000 at 05:59:48PM +1000, Alan Modra wrote:
>
> -ffunction-sections isn't a complete solution though. If two source files
> declare a local function of the same name, "setup", for instance, then
> both files will have a section called ".text.setup". These two sections
> will be merged during the "ld -r", which has the unfortunate effect of
Can you teach ld not to merge ".text.xxxxx" with -r under HPPA?
> moving a local function to a location a long way off from where it's
> called. That's bad, firstly because it means we now need a stub to reach
> the function, but more importantly the stubs are not PIC and thus need
> relocation information when creating shared libraries. In particular, for
> reasons too complicated to explain here, I don't want to create stubs for
> local functions; It would mean emitting relocs for every *potential*
> stub.
>
> Anybody know why glibc uses "ld -r", and if there is a good reason why
> we can't just remove the "ld -r"?
I don't think it has to be used. --whole-archive will do the same
trick. But "ld -r" is more convenient. With --whole-archive, you may
have to put -Wl,--whole-archive/-Wl,--no-whole-archive around each file
generarted with "ld -r"
H.J.
prev parent reply other threads:[~2000-08-17 21:22 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2000-08-17 7:59 [parisc-linux] hppa glibc ld -r Alan Modra
2000-08-17 15:23 ` H . J . Lu [this message]
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=20000817082308.B20071@lucon.org \
--to=hjl@lucon.org \
--cc=alan@linuxcare.com.au \
--cc=libc-alpha@sources.redhat.com \
--cc=parisc-linux@thepuffingroup.com \
--cc=parisc@lists.linuxcare.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.