This is the mail archive of the 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: [PATCH] Disallow copy relocation against protected data symbol

On Fri, Aug 25, 2017 at 05:17:51AM -0700, H.J. Lu wrote:
> On Thu, Aug 24, 2017 at 11:22 PM, Alan Modra <> 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.

OK, thanks for the explanation.  Since the flag is only used by the
x86 backends, please move it to elf_i386_link_hash_entry and
elf_x86_64_link_hash_entry.  You can set it via
elf_backend_merge_symbol and rearrange _bfd_elf_merge_symbol a little
so that bed->merge_symbol is called before the bfd_link_hash_new early

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]