This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH] PR target/65248: [5 Regression] Copy relocation in PIE against protected symbol
- From: "H.J. Lu" <hjl dot tools at gmail dot com>
- To: Richard Biener <richard dot guenther at gmail dot com>
- Cc: GCC Patches <gcc-patches at gcc dot gnu dot org>, Uros Bizjak <ubizjak at gmail dot com>
- Date: Mon, 2 Mar 2015 05:47:54 -0800
- Subject: Re: [PATCH] PR target/65248: [5 Regression] Copy relocation in PIE against protected symbol
- Authentication-results: sourceware.org; auth=none
- References: <20150228164223 dot GA22402 at gmail dot com> <CAFiYyc1hAR8VrML4vcDuv3Q2_EdwxEAhvPBxWpQL8tyYYX2ZGQ at mail dot gmail dot com> <20150302100959 dot GE4268 at bubble dot grove dot modra dot org> <CAFiYyc0uSb0bfWUsBte=QWOm3FRxPZ8iJyttn3ooeqK_zJ9rSQ at mail dot gmail dot com> <CAMe9rOqwRqrncZK3-RPn6uwQwvG_An5di+tJuBu2TSMSkkE+ug at mail dot gmail dot com>
On Mon, Mar 2, 2015 at 5:39 AM, H.J. Lu <hjl.tools@gmail.com> wrote:
> On Mon, Mar 2, 2015 at 4:05 AM, Richard Biener
> <richard.guenther@gmail.com> wrote:
>> On Mon, Mar 2, 2015 at 11:09 AM, Alan Modra <amodra@gmail.com> wrote:
>>> On Mon, Mar 02, 2015 at 09:40:01AM +0100, Richard Biener wrote:
>>>> On Sat, Feb 28, 2015 at 5:42 PM, H.J. Lu <hjl.tools@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?
>>>>
>>>> I wonder if the linker can fix this up? That is, turn the relocation into
>>>> a valid one?
>>>
>>> No it can't (*), nor can the dynamic linker. Copy relocs aren't
>>> really the issue. They are just a means of initializing a linker
>>> generated variable to be used in place of a variable in a shared
>>> library. The issue is the linker generated .dynbss variable itself.
>>>
>>> Consider an ELF executable linked against a shared library, with the
>>> executable referencing (but not defining) a variable defined in the
>>> shared library. You'd expect that the executable and shared library
>>> would both use the same location for the variable. Indeed, that is
>>> true. Both executable and shared library use the shared library's
>>> variable. Except there is a wrinkle. If the executable is non-PIC,
>
> ^^^^^^^^^^^^
> This is the key here. This optimization makes PIE behave like normal
> executable. Is it good or bad?
>
>>> code in the executable will require dynamic text relocations as the
>>> variable's address isn't known until run time. To avoid that, some
>>> clever person thought: "Why not have the linker define the variable in
>>> the executable? ELF run time linking semantics mean the shared
>>> library will now use the linker defined copy, so we'll still just be
>>> using one copy of the variable". Any everyone was happy. At least
>>> until ELF visibility was invented.
>>>
>>> When ELF visibility comes into play, a variable defined in a shared
>>> library with non-default visibility is *not* overridden by another
>>> definition in the executable, be it an actual definition or a linker
>>> generated one. There is no problem of course if there is an actual
>>> definition in the executable. In that case the programmer would
>>> expect to see two different variables used. However, if the shared
>>> library contains a protected visibility variable, and the linker
>>> introduces a copy, then it has changed the meaning of the program. At
>>> the source level we only had one definition of the variable, but at
>>> run time we'd end up using two different locations.
>>>
>>> *) Except by avoiding .dynbss copies and hence requiring dynamic text
>>> relocations.
>>
>> Ah, I see (protected visibility has haunted us in the past...).
>>
>> So I think we need to turn the new option off by default.
>>
By turning this optimization on by default, we make PIE behave the same
as normal executable and provide a way to change PIE behavior. This
is more consistent to users.
--
H.J.