This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
Re: [committed, PATCH] PR ld/18289: Support copy relocation in PIE
- From: Alan Modra <amodra at gmail dot com>
- To: "H.J. Lu" <hjl dot tools at gmail dot com>
- Cc: Binutils <binutils at sourceware dot org>
- Date: Fri, 24 Apr 2015 22:12:06 +0930
- Subject: Re: [committed, PATCH] PR ld/18289: Support copy relocation in PIE
- Authentication-results: sourceware.org; auth=none
- References: <20150422123523 dot GA26347 at intel dot com> <20150422230805 dot GK12627 at bubble dot grove dot modra dot org> <CAMe9rOopXa4=+xQzSQy5ALw0CE9ZRW7bj3X1BcUMAN-sf43nig at mail dot gmail dot com>
On Wed, Apr 22, 2015 at 04:24:06PM -0700, H.J. Lu wrote:
> On Wed, Apr 22, 2015 at 4:08 PM, Alan Modra <amodra@gmail.com> wrote:
> > Did you consider doing this code transformation in the linker? I
> > guess it's not so easy with variable length instructions, and you
> > would be left with a couple of nops.
>
> There can be
>
> movl optopt@GOT(%ecx), %eax
> addl $4, (%eax,%edx,4)
>
> or
>
> movl optopt@GOT(%ecx), %eax
> movl $4, (%eax,%edx,4)
>
> ...
>
> There are so many variants and there also can be instructions
> between them.
Yeah, you'd probably need marker relocs to say where the instructions
start.
> No glibc change is needed.
>
> > - No need to update all of ld, gcc, and glibc simultaneously for
> > correctness. A partial update will cause some testcases that worked
> > correctly with an older toolchain to misbehave.
>
> GCC optimization is enabled only if linker supports it.
You're correct. I wrongly thought that using the GOT in a shared
library for a protected symbol would result in it being resolved
somewhere other than the shared library. I see now that glibc has
resolved protected symbols locally for at least a dozen years..
So all my talk about needing some means of ensuring the correct
version of glibc is used was based on a false premise. Sorry for the
FUD.
--
Alan Modra
Australia Development Lab, IBM