Call _bfd_elf_symbol_refs_local_p with local_protected==true. This has
2 noticeable effects for -shared:
* GOT-generating relocations referencing a protected data symbol no
longer lead to a GLOB_DAT (similar to a hidden symbol).
* Direct access relocations (e.g. R_X86_64_PC32) no longer has the
confusing diagnostic below.
__attribute__((visibility("protected"))) void *foo() {
return (void *)foo;
}
// gcc -fpic -shared -fuse-ld=bfd
relocation R_X86_64_PC32 against protected symbol `foo' can not be used when making a shared object
The new behavior matches arm, aarch64 (commit
83c325007c), and powerpc ports, and other
linkers: gold and ld.lld.
Note: if some code tries to use direct access relocations to take the
address of foo, the pointer equality will break, but the error should be
reported on the executable link, not on the innocent shared object link.
glibc 2.36 will give a warning at relocation resolving time.
With this change, `#define elf_backend_extern_protected_data 1` is no
longer effective. Just remove it.
Remove the test "Run protected-func-1 without PIE" since -fno-pic
address taken operation in the executable doesn't work with protected
symbol in a shared object by default. Similarly, remove
protected-data-1a and protected-data-1b. protected-data-1b can be made
working by removing HAVE_LD_PIE_COPYRELOC from GCC
(https://sourceware.org/pipermail/gcc-patches/2022-June/596678.html).
