This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
Re: [PATCH] Disallow copy relocation against protected data symbol
- From: "H.J. Lu" <hjl dot tools at gmail dot com>
- To: Alan Modra <amodra at gmail dot com>
- Cc: Michael Matz <matz at suse dot de>, Binutils <binutils at sourceware dot org>
- Date: Fri, 25 Aug 2017 05:17:51 -0700
- Subject: Re: [PATCH] Disallow copy relocation against protected data symbol
- Authentication-results: sourceware.org; auth=none
- References: <CAMe9rOqcu4+aipR=kS_Ri6xkZHgy4SekKyjmLY=VFBF3wDKxaQ@mail.gmail.com> <20170825062236.GU3368@bubble.grove.modra.org>
On Thu, Aug 24, 2017 at 11:22 PM, Alan Modra <amodra@gmail.com> wrote:
> On Thu, Aug 24, 2017 at 09:13:15AM -0700, H.J. Lu wrote:
>> property. This patch adds a bit to elf_link_hash_entry and elf_obj_tdata
>
> Why is def_protected needed? Surely it is wrong to record the
> visibility of a symbol that may not even be the final definition?
> Why not just use visibility directly?
ELF_ST_VISIBILITY is only merged with relocatable input. We don't
mark an undefined symbol as protected just because the definition comes
from a protected symbol in a shared object. A protected symbol is
meaningful only for a definition with dynamic relocation.
def_protected is updated every time when def_regular or def_dynamic
is set. It tracks the visibility of the symbol definition, which can be
different from the visibility of the symbol reference. It reflects the
visibility of the final definition.
--
H.J.