[PATCH] Disallow copy relocation against protected data symbol

[H.J. Lu]

On Fri, Aug 25, 2017 at 4:46 PM, Alan Modra <amodra@gmail.com> wrote:
> 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 <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.
>
> 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
> exit.
>

elf_backend_merge_symbol_attribute is a better place to set def_protected.
This is the patch I am testing and I will check it in if it works well.

Thanks.


-- 
H.J.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-Disallow-copy-relocation-against-protected-data-symb.patch
Type: text/x-patch
Size: 30918 bytes
Desc: not available
URL: <https://sourceware.org/pipermail/binutils/attachments/20170826/9da3cbb4/attachment.bin>