On Tue, Mar 3, 2015 at 12:12 AM, Alan Modra <amo...@gmail.com> wrote: > On Mon, Mar 02, 2015 at 05:36:24AM -0800, H.J. Lu wrote: >> On Sun, Mar 1, 2015 at 11:48 PM, Uros Bizjak <ubiz...@gmail.com> wrote: >> > On Sat, Feb 28, 2015 at 5:42 PM, H.J. Lu <hjl.to...@gmail.com> wrote: >> >> Ue copy relocation in PIE improves performance. But copy relocation >> >> can't be used to access protected symbols defined in shared libaries >> >> and linker in binutils 2.26 enforces doesn't allow it. GCC doesn't >> >> know if an external definition is protected or not. This option adds >> >> -mcopyreloc-in-pie to give user an option to turn it off to avoid problem >> >> at link-time. OK for trunk? >> > >> > If the option does not work universally for all cases, then the >> > default should be off. >> >> This optimization isn't the real issue. The issue here is protected >> symbol in shared library. It can never be referenced from a normal >> executable and works correctly, as Alan explained. It doesn't matter >> if this option is off or not since it only applies to PIE. You can try >> the testcase in PR 65248 without -fPIE -pie. > > I see things differently. We have an old linker hack to avoid dynamic > text relocations in non-PIC executables. This hack doesn't work > properly with protected visibility variables in shared libraries. > Rather than blaming protected visibility variables, I say the hack is > broken. > > Since you rely on the linker hack for your optimization, you've > extended the problem from non-PIC executables to PIEs.. >
To make it clear, protected data symbols defined in shared library can never be accessed from normal executables on x86-64 since R_X86_64_PC32 relocation is used to reach externally defined symbols in small and medium models and it will overflow at run-time. On x86-64, R_X86_64_COPY relocation is required to access externally defined data symbols in normal executables unless small and medium models are removed from x86-64 psABI. For x86-64, protected data symbols are impossible. -- H.J.
