[PATCH] D19995: Optimize access to global variable references in PIE mode when linker supports copy relocations for PIE

[H.J. Lu via llvm-commits]

On Sun, May 8, 2016 at 7:46 AM, Joerg Sonnenberger via llvm-commits
<llvm-commits at lists.llvm.org> wrote:
> On Sat, May 07, 2016 at 05:39:15PM -0700, Xinliang David Li wrote:
>> On Sat, May 7, 2016 at 11:52 AM, Joerg Sonnenberger via llvm-commits <
>> llvm-commits at lists.llvm.org> wrote:
>>
>> > On Sat, May 07, 2016 at 10:58:51AM -0700, Xinliang David Li via
>> > llvm-commits wrote:
>> > > To be clear, assuming copyrelocs (support in linker) allows compiler to
>> > > generate efficient code (speculatively) to access external globals which
>> > > compiler has no idea where they are going to be defined. For most of the
>> > > cases, the most of globals end up in the main program, so copyrelocs is
>> > > only a fallback mechanism in case that is not the case.
>> >
>> > I think your reasoning is confusing cause and effect. Copy relocations
>> > exist, because people didn't want to change things when shared linkage
>> > was introduced.
>>
>>
>> What do you mean by 'people didn't want to change things'?
>
> Exactly what I wrote. Static linkage was the default, then patching with
> XCOFF. ELF's mechanism are late to the game. Copy relocations are a
> result of wanting to mix non-position independent main binaries with
> shared libraries.
>
>> For executable, copy reloc is introduced so that global access without GOT
>> can be used without requiring text relocation when the reference is truly
>> external.  Are you saying this is not the case?  History aside, this is
>> certainly how copyreloc is used today.
>
> Code generated without -fPIC on most architectures doesn't use the GOT.
> That means the link editor has to be patch things up as best as it can
> to make it use shared libraries. Two direct results from this are:
> (1) Variables defined in shared objects must be relocated to the main
> binary, when referenced from this.
> (2) The identify of functions is the PLT slot of the main binary, when
> referenced.
>
> Both issues have a long history of creating compatibility and
> performance issues.
>
>> > It is a horrible hack and everyone seriously involved
>> > with ELF acknowledges that it is a horrible hack only comparible to text
>> > relocatiions
>>
>>
>> You can certainly feel this way, but making claims about 'everyone involved
>> ..' seems to have no basis and is not relevant here.
>
> I don't see anyone disagreeing... I'm still surprised that binutils is
> willing to restore this crap, but given their history of I shouldn't be.
> I would certainly hope that Rui et al have a difference stance on repeat
> the mistakes of the past here. If you want to see a good example of why
> copy relocations are bad, look for the recent "libc++'s cout getting
> aligned differently" bug in clang. That's a wonderful example of the
> kind of issues copy relocations and where they hurt performance much
> more than any advantage they ever produce.
>

Copy relocation may change read-only data into writable:

https://sourceware.org/bugzilla/show_bug.cgi?id=19965

Lazy binding in PLT has indirect branch to the writable GOT slot.
Both have security consequences.  Is it desirable to update x86
psABI to make copy relocation and PLT optional to tighten security?

-- 
H.J.