This is the mail archive of the binutils@sourceware.org mailing list for the binutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [committed, PATCH] PR ld/18289: Support copy relocation in PIE


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]