binutils-gdb/ld/testsuite/ld-i386/protected6a.d

#source: protected6.s
#as: --32
#ld: -shared -melf_i386
#readelf: -rW
#...
There are no relocations in this file.
Replace SYMBOLIC_BIND with SYMBOL_REFERENCES_LOCAL When checking R_386_GOTOFF/R_X86_64_GOTOFF64 for building shared library, we should check SYMBOL_REFERENCES_LOCAL instead of SYMBOLIC_BIND to cover more cases. bfd/ * elf32-i386.c (elf_i386_relocate_section): Replace SYMBOLIC_BIND with SYMBOL_REFERENCES_LOCAL when checking R_386_GOTOFF against protected data symbol when building shared library. * elf64-x86-64.c (elf_x86_64_relocate_section): Check R_X86_64_GOTOFF64 against undefined symbol and replace SYMBOLIC_BIND with SYMBOL_REFERENCES_LOCAL when checking R_X86_64_GOTOFF64 against protected data symbol when building shared library. ld/testsuite/ * ld-i386/i386.exp: Run protected6a. * ld-i386/protected6.d: Renamed to ... * ld-i386/protected6a.d: This. * ld-x86-64/hidden4.d: New file. * ld-x86-64/hidden4.s: Likewise. * ld-x86-64/hidden5.d: Likewise. * ld-x86-64/hidden5.s: Likewise. * ld-x86-64/protected6.d: Renamed to ... * ld-x86-64/protected6a.d: This. * ld-x86-64/x86-64.exp: Run hidden4, hidden5, protected6a, protected7a and protected7b. 2015-04-11 22:34:49 +08:00			`#source: protected6.s`
Check GOTOFF reloc against protected data on x86 R_386_GOTOFF/R_X86_64_GOTOFF64 relocation shouldn't be used against protected data symbol on x86 since with copy relocation, address of protected data defined in the shared library may be external. This patch will break building shared libraries with protected data symbols using GCCs older than GCC 5 without the bug fix for https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65248 GCC backport request should be made in the GCC bug report above. bfd/ PR ld/pr17709 * elf32-i386.c (elf_i386_relocate_section): Also check R_386_GOTOFF against protected data symbol when building shared library. * elf64-x86-64.c (elf_x86_64_relocate_section): Also check R_X86_64_GOTOFF64 against protected data symbol when building shared library. ld/testsuite/ PR ld/pr17709 * ld-i386/protected6.d: New file. * ld-i386/protected6.s: Likewise. * ld-x86-64/protected6.d: Likewise. * ld-x86-64/protected6.s: Likewise. * ld-x86-64/protected7.d: Likewise. * ld-x86-64/protected7.s: Likewise. * ld-x86-64/protected7a.d: Likewise. * ld-x86-64/protected7b.d: Likewise. 2015-04-11 05:02:23 +08:00			`#as: --32`
			`#ld: -shared -melf_i386`
x86: Make protected symbols local for -shared 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 83c325007c5599fa9b60b8d5f7b84842160e1d1b), 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). 2022-06-26 01:44:26 +08:00			`#readelf: -rW`
			`#...`
			`There are no relocations in this file.`