maxjhandsome
/
llvm-project
forked from OSchip/llvm-project
1
0
Fork 0
Code Issues Pull Requests Packages Releases Wiki Activity
llvm-project/lld/test/ELF/bsymbolic.s

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

165 lines
5.3 KiB
ArmAsm
Raw Normal View History

[ELF][test] Improve -Bsymbolic & -Bsymbolic-functions test Previously there was no test checking that -Bsymbolic-functions only applies to STT_FUNC symbols. Reviewed By: jhenderson Differential Revision: https://reviews.llvm.org/D102461
2021-05-15 00:33:43 +08:00
# REQUIRES: x86
# RUN: rm -rf %t && split-file %s %t
# RUN: llvm-mc -filetype=obj -triple=x86_64 %t/a.s -o %t/a.o
# RUN: llvm-mc -filetype=obj -triple=x86_64 %t/b.s -o %t/b.o
# RUN: ld.lld -shared %t/a.o %t/b.o -o %t0.so
# RUN: llvm-readobj -r %t0.so | FileCheck %s --check-prefix=REL_DEF
# RUN: llvm-objdump -d %t0.so | FileCheck %s --check-prefix=ASM_DEF
[ELF] Add -Bsymbolic-non-weak-functions This option is a subset of -Bsymbolic-functions. It applies to STB_GLOBAL STT_FUNC definitions. The address of a vague linkage function (STB_WEAK STT_FUNC, e.g. an inline function, a template instantiation) seen by a -Bsymbolic-functions linked shared object may be different from the address seen from outside the shared object. Such cases are uncommon. (ELF/Mach-O programs may use `-fvisibility-inlines-hidden` to break such pointer equality. On Windows, correct dllexport and dllimport are needed to make pointer equality work. Windows link.exe enables /OPT:ICF by default so different inline functions may have the same address.) ``` // a.cc -> a.o -> a.so (-Bsymbolic-functions) inline void f() {} void *g() { return (void *)&f; } // b.cc -> b.o -> exe // The address is different! inline void f() {} ``` -Bsymbolic-non-weak-functions is a safer (C++ conforming) subset of -Bsymbolic-functions, which can make such programs work. Implementations usually emit a vague linkage definition in a COMDAT group. We could detect the group (with more code) but I feel that we should just check STB_WEAK for simplicity. A weak definition will thus serve as an escape hatch for rare cases when users want interposition on definitions. GNU ld feature request: https://sourceware.org/bugzilla/show_bug.cgi?id=27871 Longer write-up: https://maskray.me/blog/2021-05-16-elf-interposition-and-bsymbolic If Linux distributions migrate to protected non-vague-linkage external linkage functions by default, the linker option can still be handy because it allows rapid experiment without recompilation. Protected function addresses currently have deep issues in GNU ld. Reviewed By: peter.smith Differential Revision: https://reviews.llvm.org/D102570
2021-07-30 05:46:53 +08:00
## -Bsymbolic-functions makes all STB_GLOBAL STT_FUNC definitions non-preemptible.
# RUN: ld.lld -shared -Bsymbolic-non-weak-functions %t/a.o %t/b.o -o %t1.so
# RUN: llvm-readobj -r %t1.so | FileCheck %s --check-prefix=REL_GFUN
# RUN: llvm-objdump -d %t1.so | FileCheck %s --check-prefix=ASM_GFUN
[ELF][test] Improve -Bsymbolic & -Bsymbolic-functions test Previously there was no test checking that -Bsymbolic-functions only applies to STT_FUNC symbols. Reviewed By: jhenderson Differential Revision: https://reviews.llvm.org/D102461
2021-05-15 00:33:43 +08:00
## -Bsymbolic-functions makes all STT_FUNC definitions non-preemptible.
[ELF] Add -Bsymbolic-non-weak-functions This option is a subset of -Bsymbolic-functions. It applies to STB_GLOBAL STT_FUNC definitions. The address of a vague linkage function (STB_WEAK STT_FUNC, e.g. an inline function, a template instantiation) seen by a -Bsymbolic-functions linked shared object may be different from the address seen from outside the shared object. Such cases are uncommon. (ELF/Mach-O programs may use `-fvisibility-inlines-hidden` to break such pointer equality. On Windows, correct dllexport and dllimport are needed to make pointer equality work. Windows link.exe enables /OPT:ICF by default so different inline functions may have the same address.) ``` // a.cc -> a.o -> a.so (-Bsymbolic-functions) inline void f() {} void *g() { return (void *)&f; } // b.cc -> b.o -> exe // The address is different! inline void f() {} ``` -Bsymbolic-non-weak-functions is a safer (C++ conforming) subset of -Bsymbolic-functions, which can make such programs work. Implementations usually emit a vague linkage definition in a COMDAT group. We could detect the group (with more code) but I feel that we should just check STB_WEAK for simplicity. A weak definition will thus serve as an escape hatch for rare cases when users want interposition on definitions. GNU ld feature request: https://sourceware.org/bugzilla/show_bug.cgi?id=27871 Longer write-up: https://maskray.me/blog/2021-05-16-elf-interposition-and-bsymbolic If Linux distributions migrate to protected non-vague-linkage external linkage functions by default, the linker option can still be handy because it allows rapid experiment without recompilation. Protected function addresses currently have deep issues in GNU ld. Reviewed By: peter.smith Differential Revision: https://reviews.llvm.org/D102570
2021-07-30 05:46:53 +08:00
# RUN: ld.lld -shared -Bsymbolic-functions %t/a.o %t/b.o -o %t2.so
# RUN: llvm-readobj -r %t2.so | FileCheck %s --check-prefix=REL_FUN
# RUN: llvm-objdump -d %t2.so | FileCheck %s --check-prefix=ASM_FUN
[ELF][test] Improve -Bsymbolic & -Bsymbolic-functions test Previously there was no test checking that -Bsymbolic-functions only applies to STT_FUNC symbols. Reviewed By: jhenderson Differential Revision: https://reviews.llvm.org/D102461
2021-05-15 00:33:43 +08:00
## -Bsymbolic makes all definitions non-preemptible.
[ELF] Add -Bsymbolic-non-weak-functions This option is a subset of -Bsymbolic-functions. It applies to STB_GLOBAL STT_FUNC definitions. The address of a vague linkage function (STB_WEAK STT_FUNC, e.g. an inline function, a template instantiation) seen by a -Bsymbolic-functions linked shared object may be different from the address seen from outside the shared object. Such cases are uncommon. (ELF/Mach-O programs may use `-fvisibility-inlines-hidden` to break such pointer equality. On Windows, correct dllexport and dllimport are needed to make pointer equality work. Windows link.exe enables /OPT:ICF by default so different inline functions may have the same address.) ``` // a.cc -> a.o -> a.so (-Bsymbolic-functions) inline void f() {} void *g() { return (void *)&f; } // b.cc -> b.o -> exe // The address is different! inline void f() {} ``` -Bsymbolic-non-weak-functions is a safer (C++ conforming) subset of -Bsymbolic-functions, which can make such programs work. Implementations usually emit a vague linkage definition in a COMDAT group. We could detect the group (with more code) but I feel that we should just check STB_WEAK for simplicity. A weak definition will thus serve as an escape hatch for rare cases when users want interposition on definitions. GNU ld feature request: https://sourceware.org/bugzilla/show_bug.cgi?id=27871 Longer write-up: https://maskray.me/blog/2021-05-16-elf-interposition-and-bsymbolic If Linux distributions migrate to protected non-vague-linkage external linkage functions by default, the linker option can still be handy because it allows rapid experiment without recompilation. Protected function addresses currently have deep issues in GNU ld. Reviewed By: peter.smith Differential Revision: https://reviews.llvm.org/D102570
2021-07-30 05:46:53 +08:00
# RUN: ld.lld -shared -Bsymbolic %t/a.o %t/b.o -o %t3.so
# RUN: llvm-readobj -r %t3.so | FileCheck %s --check-prefix=REL_ALL
# RUN: llvm-objdump -d %t3.so | FileCheck %s --check-prefix=ASM_ALL
[ELF][test] Improve -Bsymbolic & -Bsymbolic-functions test Previously there was no test checking that -Bsymbolic-functions only applies to STT_FUNC symbols. Reviewed By: jhenderson Differential Revision: https://reviews.llvm.org/D102461
2021-05-15 00:33:43 +08:00
# RUN: ld.lld -shared -Bsymbolic-functions -Bsymbolic %t/a.o %t/b.o -o %t.so
[ELF] Add -Bsymbolic-non-weak-functions This option is a subset of -Bsymbolic-functions. It applies to STB_GLOBAL STT_FUNC definitions. The address of a vague linkage function (STB_WEAK STT_FUNC, e.g. an inline function, a template instantiation) seen by a -Bsymbolic-functions linked shared object may be different from the address seen from outside the shared object. Such cases are uncommon. (ELF/Mach-O programs may use `-fvisibility-inlines-hidden` to break such pointer equality. On Windows, correct dllexport and dllimport are needed to make pointer equality work. Windows link.exe enables /OPT:ICF by default so different inline functions may have the same address.) ``` // a.cc -> a.o -> a.so (-Bsymbolic-functions) inline void f() {} void *g() { return (void *)&f; } // b.cc -> b.o -> exe // The address is different! inline void f() {} ``` -Bsymbolic-non-weak-functions is a safer (C++ conforming) subset of -Bsymbolic-functions, which can make such programs work. Implementations usually emit a vague linkage definition in a COMDAT group. We could detect the group (with more code) but I feel that we should just check STB_WEAK for simplicity. A weak definition will thus serve as an escape hatch for rare cases when users want interposition on definitions. GNU ld feature request: https://sourceware.org/bugzilla/show_bug.cgi?id=27871 Longer write-up: https://maskray.me/blog/2021-05-16-elf-interposition-and-bsymbolic If Linux distributions migrate to protected non-vague-linkage external linkage functions by default, the linker option can still be handy because it allows rapid experiment without recompilation. Protected function addresses currently have deep issues in GNU ld. Reviewed By: peter.smith Differential Revision: https://reviews.llvm.org/D102570
2021-07-30 05:46:53 +08:00
# RUN: cmp %t.so %t3.so
[ELF][test] Improve -Bsymbolic & -Bsymbolic-functions test Previously there was no test checking that -Bsymbolic-functions only applies to STT_FUNC symbols. Reviewed By: jhenderson Differential Revision: https://reviews.llvm.org/D102461
2021-05-15 00:33:43 +08:00
# RUN: ld.lld -shared -Bsymbolic -Bsymbolic-functions %t/a.o %t/b.o -o %t.so
# RUN: cmp %t.so %t2.so
[ELF] Add -Bsymbolic-non-weak-functions This option is a subset of -Bsymbolic-functions. It applies to STB_GLOBAL STT_FUNC definitions. The address of a vague linkage function (STB_WEAK STT_FUNC, e.g. an inline function, a template instantiation) seen by a -Bsymbolic-functions linked shared object may be different from the address seen from outside the shared object. Such cases are uncommon. (ELF/Mach-O programs may use `-fvisibility-inlines-hidden` to break such pointer equality. On Windows, correct dllexport and dllimport are needed to make pointer equality work. Windows link.exe enables /OPT:ICF by default so different inline functions may have the same address.) ``` // a.cc -> a.o -> a.so (-Bsymbolic-functions) inline void f() {} void *g() { return (void *)&f; } // b.cc -> b.o -> exe // The address is different! inline void f() {} ``` -Bsymbolic-non-weak-functions is a safer (C++ conforming) subset of -Bsymbolic-functions, which can make such programs work. Implementations usually emit a vague linkage definition in a COMDAT group. We could detect the group (with more code) but I feel that we should just check STB_WEAK for simplicity. A weak definition will thus serve as an escape hatch for rare cases when users want interposition on definitions. GNU ld feature request: https://sourceware.org/bugzilla/show_bug.cgi?id=27871 Longer write-up: https://maskray.me/blog/2021-05-16-elf-interposition-and-bsymbolic If Linux distributions migrate to protected non-vague-linkage external linkage functions by default, the linker option can still be handy because it allows rapid experiment without recompilation. Protected function addresses currently have deep issues in GNU ld. Reviewed By: peter.smith Differential Revision: https://reviews.llvm.org/D102570
2021-07-30 05:46:53 +08:00
# RUN: ld.lld -shared -Bno-symbolic -Bsymbolic %t/a.o %t/b.o -o %t.so
# RUN: cmp %t.so %t3.so
[ELF][test] Improve -Bsymbolic & -Bsymbolic-functions test Previously there was no test checking that -Bsymbolic-functions only applies to STT_FUNC symbols. Reviewed By: jhenderson Differential Revision: https://reviews.llvm.org/D102461
2021-05-15 00:33:43 +08:00
[ELF] Add -Bno-symbolic This option will be available in GNU ld 2.27 (https://sourceware.org/bugzilla/show_bug.cgi?id=27834). This option can cancel previously specified -Bsymbolic and -Bsymbolic-functions. This is useful for excluding some links when the default uses -Bsymbolic-functions. Reviewed By: jhenderson, peter.smith Differential Revision: https://reviews.llvm.org/D102383
2021-05-15 00:40:32 +08:00
## -Bno-symbolic can cancel previously specified -Bsymbolic and -Bsymbolic-functions.
# RUN: ld.lld -shared -Bsymbolic -Bno-symbolic %t/a.o %t/b.o -o %t.so
# RUN: cmp %t.so %t0.so
# RUN: ld.lld -shared -Bsymbolic-functions -Bno-symbolic %t/a.o %t/b.o -o %t.so
# RUN: cmp %t.so %t0.so
[ELF][test] Improve -Bsymbolic & -Bsymbolic-functions test Previously there was no test checking that -Bsymbolic-functions only applies to STT_FUNC symbols. Reviewed By: jhenderson Differential Revision: https://reviews.llvm.org/D102461
2021-05-15 00:33:43 +08:00
# REL_DEF: .rela.dyn {
# REL_DEF-NEXT: R_X86_64_RELATIVE -
# REL_DEF-NEXT: R_X86_64_RELATIVE -
# REL_DEF-NEXT: R_X86_64_64 data_default
# REL_DEF-NEXT: }
# REL_DEF-NEXT: .rela.plt {
# REL_DEF-NEXT: R_X86_64_JUMP_SLOT default
[ELF] Add -Bsymbolic-non-weak-functions This option is a subset of -Bsymbolic-functions. It applies to STB_GLOBAL STT_FUNC definitions. The address of a vague linkage function (STB_WEAK STT_FUNC, e.g. an inline function, a template instantiation) seen by a -Bsymbolic-functions linked shared object may be different from the address seen from outside the shared object. Such cases are uncommon. (ELF/Mach-O programs may use `-fvisibility-inlines-hidden` to break such pointer equality. On Windows, correct dllexport and dllimport are needed to make pointer equality work. Windows link.exe enables /OPT:ICF by default so different inline functions may have the same address.) ``` // a.cc -> a.o -> a.so (-Bsymbolic-functions) inline void f() {} void *g() { return (void *)&f; } // b.cc -> b.o -> exe // The address is different! inline void f() {} ``` -Bsymbolic-non-weak-functions is a safer (C++ conforming) subset of -Bsymbolic-functions, which can make such programs work. Implementations usually emit a vague linkage definition in a COMDAT group. We could detect the group (with more code) but I feel that we should just check STB_WEAK for simplicity. A weak definition will thus serve as an escape hatch for rare cases when users want interposition on definitions. GNU ld feature request: https://sourceware.org/bugzilla/show_bug.cgi?id=27871 Longer write-up: https://maskray.me/blog/2021-05-16-elf-interposition-and-bsymbolic If Linux distributions migrate to protected non-vague-linkage external linkage functions by default, the linker option can still be handy because it allows rapid experiment without recompilation. Protected function addresses currently have deep issues in GNU ld. Reviewed By: peter.smith Differential Revision: https://reviews.llvm.org/D102570
2021-07-30 05:46:53 +08:00
# REL_DEF-NEXT: R_X86_64_JUMP_SLOT weak_default
[ELF][test] Improve -Bsymbolic & -Bsymbolic-functions test Previously there was no test checking that -Bsymbolic-functions only applies to STT_FUNC symbols. Reviewed By: jhenderson Differential Revision: https://reviews.llvm.org/D102461
2021-05-15 00:33:43 +08:00
# REL_DEF-NEXT: R_X86_64_JUMP_SLOT ext_default
# REL_DEF-NEXT: R_X86_64_JUMP_SLOT notype_default
# REL_DEF-NEXT: R_X86_64_JUMP_SLOT undef
# REL_DEF-NEXT: }
# ASM_DEF: <_start>:
# ASM_DEF-NEXT: callq {{.*}} <default@plt>
# ASM_DEF-NEXT: callq {{.*}} <protected>
# ASM_DEF-NEXT: callq {{.*}} <hidden>
[ELF] Add -Bsymbolic-non-weak-functions This option is a subset of -Bsymbolic-functions. It applies to STB_GLOBAL STT_FUNC definitions. The address of a vague linkage function (STB_WEAK STT_FUNC, e.g. an inline function, a template instantiation) seen by a -Bsymbolic-functions linked shared object may be different from the address seen from outside the shared object. Such cases are uncommon. (ELF/Mach-O programs may use `-fvisibility-inlines-hidden` to break such pointer equality. On Windows, correct dllexport and dllimport are needed to make pointer equality work. Windows link.exe enables /OPT:ICF by default so different inline functions may have the same address.) ``` // a.cc -> a.o -> a.so (-Bsymbolic-functions) inline void f() {} void *g() { return (void *)&f; } // b.cc -> b.o -> exe // The address is different! inline void f() {} ``` -Bsymbolic-non-weak-functions is a safer (C++ conforming) subset of -Bsymbolic-functions, which can make such programs work. Implementations usually emit a vague linkage definition in a COMDAT group. We could detect the group (with more code) but I feel that we should just check STB_WEAK for simplicity. A weak definition will thus serve as an escape hatch for rare cases when users want interposition on definitions. GNU ld feature request: https://sourceware.org/bugzilla/show_bug.cgi?id=27871 Longer write-up: https://maskray.me/blog/2021-05-16-elf-interposition-and-bsymbolic If Linux distributions migrate to protected non-vague-linkage external linkage functions by default, the linker option can still be handy because it allows rapid experiment without recompilation. Protected function addresses currently have deep issues in GNU ld. Reviewed By: peter.smith Differential Revision: https://reviews.llvm.org/D102570
2021-07-30 05:46:53 +08:00
# ASM_DEF-NEXT: callq {{.*}} <weak_default@plt>
[ELF][test] Improve -Bsymbolic & -Bsymbolic-functions test Previously there was no test checking that -Bsymbolic-functions only applies to STT_FUNC symbols. Reviewed By: jhenderson Differential Revision: https://reviews.llvm.org/D102461
2021-05-15 00:33:43 +08:00
# ASM_DEF-NEXT: callq {{.*}} <ext_default@plt>
# ASM_DEF-NEXT: callq {{.*}} <notype_default@plt>
# ASM_DEF-NEXT: callq {{.*}} <undef@plt>
[ELF] Add -Bsymbolic-non-weak-functions This option is a subset of -Bsymbolic-functions. It applies to STB_GLOBAL STT_FUNC definitions. The address of a vague linkage function (STB_WEAK STT_FUNC, e.g. an inline function, a template instantiation) seen by a -Bsymbolic-functions linked shared object may be different from the address seen from outside the shared object. Such cases are uncommon. (ELF/Mach-O programs may use `-fvisibility-inlines-hidden` to break such pointer equality. On Windows, correct dllexport and dllimport are needed to make pointer equality work. Windows link.exe enables /OPT:ICF by default so different inline functions may have the same address.) ``` // a.cc -> a.o -> a.so (-Bsymbolic-functions) inline void f() {} void *g() { return (void *)&f; } // b.cc -> b.o -> exe // The address is different! inline void f() {} ``` -Bsymbolic-non-weak-functions is a safer (C++ conforming) subset of -Bsymbolic-functions, which can make such programs work. Implementations usually emit a vague linkage definition in a COMDAT group. We could detect the group (with more code) but I feel that we should just check STB_WEAK for simplicity. A weak definition will thus serve as an escape hatch for rare cases when users want interposition on definitions. GNU ld feature request: https://sourceware.org/bugzilla/show_bug.cgi?id=27871 Longer write-up: https://maskray.me/blog/2021-05-16-elf-interposition-and-bsymbolic If Linux distributions migrate to protected non-vague-linkage external linkage functions by default, the linker option can still be handy because it allows rapid experiment without recompilation. Protected function addresses currently have deep issues in GNU ld. Reviewed By: peter.smith Differential Revision: https://reviews.llvm.org/D102570
2021-07-30 05:46:53 +08:00
# REL_GFUN: .rela.dyn {
# REL_GFUN-NEXT: R_X86_64_RELATIVE -
# REL_GFUN-NEXT: R_X86_64_RELATIVE -
# REL_GFUN-NEXT: R_X86_64_64 data_default
# REL_GFUN-NEXT: }
# REL_GFUN-NEXT: .rela.plt {
# REL_GFUN-NEXT: R_X86_64_JUMP_SLOT weak_default
# REL_GFUN-NEXT: R_X86_64_JUMP_SLOT notype_default
# REL_GFUN-NEXT: R_X86_64_JUMP_SLOT undef
# REL_GFUN-NEXT: }
# ASM_GFUN: <_start>:
# ASM_GFUN-NEXT: callq {{.*}} <default>
# ASM_GFUN-NEXT: callq {{.*}} <protected>
# ASM_GFUN-NEXT: callq {{.*}} <hidden>
# ASM_GFUN-NEXT: callq {{.*}} <weak_default@plt>
# ASM_GFUN-NEXT: callq {{.*}} <ext_default>
# ASM_GFUN-NEXT: callq {{.*}} <notype_default@plt>
# ASM_GFUN-NEXT: callq {{.*}} <undef@plt>
[ELF][test] Improve -Bsymbolic & -Bsymbolic-functions test Previously there was no test checking that -Bsymbolic-functions only applies to STT_FUNC symbols. Reviewed By: jhenderson Differential Revision: https://reviews.llvm.org/D102461
2021-05-15 00:33:43 +08:00
# REL_FUN: .rela.dyn {
# REL_FUN-NEXT: R_X86_64_RELATIVE -
# REL_FUN-NEXT: R_X86_64_RELATIVE -
# REL_FUN-NEXT: R_X86_64_64 data_default
# REL_FUN-NEXT: }
# REL_FUN-NEXT: .rela.plt {
# REL_FUN-NEXT: R_X86_64_JUMP_SLOT notype_default
# REL_FUN-NEXT: R_X86_64_JUMP_SLOT undef
# REL_FUN-NEXT: }
# ASM_FUN: <_start>:
# ASM_FUN-NEXT: callq {{.*}} <default>
# ASM_FUN-NEXT: callq {{.*}} <protected>
# ASM_FUN-NEXT: callq {{.*}} <hidden>
[ELF] Add -Bsymbolic-non-weak-functions This option is a subset of -Bsymbolic-functions. It applies to STB_GLOBAL STT_FUNC definitions. The address of a vague linkage function (STB_WEAK STT_FUNC, e.g. an inline function, a template instantiation) seen by a -Bsymbolic-functions linked shared object may be different from the address seen from outside the shared object. Such cases are uncommon. (ELF/Mach-O programs may use `-fvisibility-inlines-hidden` to break such pointer equality. On Windows, correct dllexport and dllimport are needed to make pointer equality work. Windows link.exe enables /OPT:ICF by default so different inline functions may have the same address.) ``` // a.cc -> a.o -> a.so (-Bsymbolic-functions) inline void f() {} void *g() { return (void *)&f; } // b.cc -> b.o -> exe // The address is different! inline void f() {} ``` -Bsymbolic-non-weak-functions is a safer (C++ conforming) subset of -Bsymbolic-functions, which can make such programs work. Implementations usually emit a vague linkage definition in a COMDAT group. We could detect the group (with more code) but I feel that we should just check STB_WEAK for simplicity. A weak definition will thus serve as an escape hatch for rare cases when users want interposition on definitions. GNU ld feature request: https://sourceware.org/bugzilla/show_bug.cgi?id=27871 Longer write-up: https://maskray.me/blog/2021-05-16-elf-interposition-and-bsymbolic If Linux distributions migrate to protected non-vague-linkage external linkage functions by default, the linker option can still be handy because it allows rapid experiment without recompilation. Protected function addresses currently have deep issues in GNU ld. Reviewed By: peter.smith Differential Revision: https://reviews.llvm.org/D102570
2021-07-30 05:46:53 +08:00
# ASM_FUN-NEXT: callq {{.*}} <weak_default>
[ELF][test] Improve -Bsymbolic & -Bsymbolic-functions test Previously there was no test checking that -Bsymbolic-functions only applies to STT_FUNC symbols. Reviewed By: jhenderson Differential Revision: https://reviews.llvm.org/D102461
2021-05-15 00:33:43 +08:00
# ASM_FUN-NEXT: callq {{.*}} <ext_default>
# ASM_FUN-NEXT: callq {{.*}} <notype_default@plt>
# ASM_FUN-NEXT: callq {{.*}} <undef@plt>
# REL_ALL: .rela.dyn {
# REL_ALL-NEXT: R_X86_64_RELATIVE -
# REL_ALL-NEXT: R_X86_64_RELATIVE -
# REL_ALL-NEXT: R_X86_64_RELATIVE -
# REL_ALL-NEXT: }
# REL_ALL-NEXT: .rela.plt {
# REL_ALL-NEXT: R_X86_64_JUMP_SLOT undef
# REL_ALL-NEXT: }
# ASM_ALL: <_start>:
# ASM_ALL-NEXT: callq {{.*}} <default>
# ASM_ALL-NEXT: callq {{.*}} <protected>
# ASM_ALL-NEXT: callq {{.*}} <hidden>
[ELF] Add -Bsymbolic-non-weak-functions This option is a subset of -Bsymbolic-functions. It applies to STB_GLOBAL STT_FUNC definitions. The address of a vague linkage function (STB_WEAK STT_FUNC, e.g. an inline function, a template instantiation) seen by a -Bsymbolic-functions linked shared object may be different from the address seen from outside the shared object. Such cases are uncommon. (ELF/Mach-O programs may use `-fvisibility-inlines-hidden` to break such pointer equality. On Windows, correct dllexport and dllimport are needed to make pointer equality work. Windows link.exe enables /OPT:ICF by default so different inline functions may have the same address.) ``` // a.cc -> a.o -> a.so (-Bsymbolic-functions) inline void f() {} void *g() { return (void *)&f; } // b.cc -> b.o -> exe // The address is different! inline void f() {} ``` -Bsymbolic-non-weak-functions is a safer (C++ conforming) subset of -Bsymbolic-functions, which can make such programs work. Implementations usually emit a vague linkage definition in a COMDAT group. We could detect the group (with more code) but I feel that we should just check STB_WEAK for simplicity. A weak definition will thus serve as an escape hatch for rare cases when users want interposition on definitions. GNU ld feature request: https://sourceware.org/bugzilla/show_bug.cgi?id=27871 Longer write-up: https://maskray.me/blog/2021-05-16-elf-interposition-and-bsymbolic If Linux distributions migrate to protected non-vague-linkage external linkage functions by default, the linker option can still be handy because it allows rapid experiment without recompilation. Protected function addresses currently have deep issues in GNU ld. Reviewed By: peter.smith Differential Revision: https://reviews.llvm.org/D102570
2021-07-30 05:46:53 +08:00
# ASM_ALL-NEXT: callq {{.*}} <weak_default>
[ELF][test] Improve -Bsymbolic & -Bsymbolic-functions test Previously there was no test checking that -Bsymbolic-functions only applies to STT_FUNC symbols. Reviewed By: jhenderson Differential Revision: https://reviews.llvm.org/D102461
2021-05-15 00:33:43 +08:00
# ASM_ALL-NEXT: callq {{.*}} <ext_default>
# ASM_ALL-NEXT: callq {{.*}} <notype_default>
# ASM_ALL-NEXT: callq {{.*}} <undef@plt>
#--- a.s
.globl default, protected, hidden, notype_default
[ELF] Add -Bsymbolic-non-weak-functions This option is a subset of -Bsymbolic-functions. It applies to STB_GLOBAL STT_FUNC definitions. The address of a vague linkage function (STB_WEAK STT_FUNC, e.g. an inline function, a template instantiation) seen by a -Bsymbolic-functions linked shared object may be different from the address seen from outside the shared object. Such cases are uncommon. (ELF/Mach-O programs may use `-fvisibility-inlines-hidden` to break such pointer equality. On Windows, correct dllexport and dllimport are needed to make pointer equality work. Windows link.exe enables /OPT:ICF by default so different inline functions may have the same address.) ``` // a.cc -> a.o -> a.so (-Bsymbolic-functions) inline void f() {} void *g() { return (void *)&f; } // b.cc -> b.o -> exe // The address is different! inline void f() {} ``` -Bsymbolic-non-weak-functions is a safer (C++ conforming) subset of -Bsymbolic-functions, which can make such programs work. Implementations usually emit a vague linkage definition in a COMDAT group. We could detect the group (with more code) but I feel that we should just check STB_WEAK for simplicity. A weak definition will thus serve as an escape hatch for rare cases when users want interposition on definitions. GNU ld feature request: https://sourceware.org/bugzilla/show_bug.cgi?id=27871 Longer write-up: https://maskray.me/blog/2021-05-16-elf-interposition-and-bsymbolic If Linux distributions migrate to protected non-vague-linkage external linkage functions by default, the linker option can still be handy because it allows rapid experiment without recompilation. Protected function addresses currently have deep issues in GNU ld. Reviewed By: peter.smith Differential Revision: https://reviews.llvm.org/D102570
2021-07-30 05:46:53 +08:00
.weak weak_default
[ELF][test] Improve -Bsymbolic & -Bsymbolic-functions test Previously there was no test checking that -Bsymbolic-functions only applies to STT_FUNC symbols. Reviewed By: jhenderson Differential Revision: https://reviews.llvm.org/D102461
2021-05-15 00:33:43 +08:00
.protected protected
.hidden hidden
.type default, @function
.type protected, @function
.type hidden, @function
[ELF] Add -Bsymbolic-non-weak-functions This option is a subset of -Bsymbolic-functions. It applies to STB_GLOBAL STT_FUNC definitions. The address of a vague linkage function (STB_WEAK STT_FUNC, e.g. an inline function, a template instantiation) seen by a -Bsymbolic-functions linked shared object may be different from the address seen from outside the shared object. Such cases are uncommon. (ELF/Mach-O programs may use `-fvisibility-inlines-hidden` to break such pointer equality. On Windows, correct dllexport and dllimport are needed to make pointer equality work. Windows link.exe enables /OPT:ICF by default so different inline functions may have the same address.) ``` // a.cc -> a.o -> a.so (-Bsymbolic-functions) inline void f() {} void *g() { return (void *)&f; } // b.cc -> b.o -> exe // The address is different! inline void f() {} ``` -Bsymbolic-non-weak-functions is a safer (C++ conforming) subset of -Bsymbolic-functions, which can make such programs work. Implementations usually emit a vague linkage definition in a COMDAT group. We could detect the group (with more code) but I feel that we should just check STB_WEAK for simplicity. A weak definition will thus serve as an escape hatch for rare cases when users want interposition on definitions. GNU ld feature request: https://sourceware.org/bugzilla/show_bug.cgi?id=27871 Longer write-up: https://maskray.me/blog/2021-05-16-elf-interposition-and-bsymbolic If Linux distributions migrate to protected non-vague-linkage external linkage functions by default, the linker option can still be handy because it allows rapid experiment without recompilation. Protected function addresses currently have deep issues in GNU ld. Reviewed By: peter.smith Differential Revision: https://reviews.llvm.org/D102570
2021-07-30 05:46:53 +08:00
.type weak_default, @function
[ELF][test] Improve -Bsymbolic & -Bsymbolic-functions test Previously there was no test checking that -Bsymbolic-functions only applies to STT_FUNC symbols. Reviewed By: jhenderson Differential Revision: https://reviews.llvm.org/D102461
2021-05-15 00:33:43 +08:00
default: nop
protected: nop
hidden: nop
[ELF] Add -Bsymbolic-non-weak-functions This option is a subset of -Bsymbolic-functions. It applies to STB_GLOBAL STT_FUNC definitions. The address of a vague linkage function (STB_WEAK STT_FUNC, e.g. an inline function, a template instantiation) seen by a -Bsymbolic-functions linked shared object may be different from the address seen from outside the shared object. Such cases are uncommon. (ELF/Mach-O programs may use `-fvisibility-inlines-hidden` to break such pointer equality. On Windows, correct dllexport and dllimport are needed to make pointer equality work. Windows link.exe enables /OPT:ICF by default so different inline functions may have the same address.) ``` // a.cc -> a.o -> a.so (-Bsymbolic-functions) inline void f() {} void *g() { return (void *)&f; } // b.cc -> b.o -> exe // The address is different! inline void f() {} ``` -Bsymbolic-non-weak-functions is a safer (C++ conforming) subset of -Bsymbolic-functions, which can make such programs work. Implementations usually emit a vague linkage definition in a COMDAT group. We could detect the group (with more code) but I feel that we should just check STB_WEAK for simplicity. A weak definition will thus serve as an escape hatch for rare cases when users want interposition on definitions. GNU ld feature request: https://sourceware.org/bugzilla/show_bug.cgi?id=27871 Longer write-up: https://maskray.me/blog/2021-05-16-elf-interposition-and-bsymbolic If Linux distributions migrate to protected non-vague-linkage external linkage functions by default, the linker option can still be handy because it allows rapid experiment without recompilation. Protected function addresses currently have deep issues in GNU ld. Reviewed By: peter.smith Differential Revision: https://reviews.llvm.org/D102570
2021-07-30 05:46:53 +08:00
weak_default: nop
[ELF][test] Improve -Bsymbolic & -Bsymbolic-functions test Previously there was no test checking that -Bsymbolic-functions only applies to STT_FUNC symbols. Reviewed By: jhenderson Differential Revision: https://reviews.llvm.org/D102461
2021-05-15 00:33:43 +08:00
notype_default: nop
.globl _start
_start:
callq default@PLT
callq protected@PLT
callq hidden@PLT
[ELF] Add -Bsymbolic-non-weak-functions This option is a subset of -Bsymbolic-functions. It applies to STB_GLOBAL STT_FUNC definitions. The address of a vague linkage function (STB_WEAK STT_FUNC, e.g. an inline function, a template instantiation) seen by a -Bsymbolic-functions linked shared object may be different from the address seen from outside the shared object. Such cases are uncommon. (ELF/Mach-O programs may use `-fvisibility-inlines-hidden` to break such pointer equality. On Windows, correct dllexport and dllimport are needed to make pointer equality work. Windows link.exe enables /OPT:ICF by default so different inline functions may have the same address.) ``` // a.cc -> a.o -> a.so (-Bsymbolic-functions) inline void f() {} void *g() { return (void *)&f; } // b.cc -> b.o -> exe // The address is different! inline void f() {} ``` -Bsymbolic-non-weak-functions is a safer (C++ conforming) subset of -Bsymbolic-functions, which can make such programs work. Implementations usually emit a vague linkage definition in a COMDAT group. We could detect the group (with more code) but I feel that we should just check STB_WEAK for simplicity. A weak definition will thus serve as an escape hatch for rare cases when users want interposition on definitions. GNU ld feature request: https://sourceware.org/bugzilla/show_bug.cgi?id=27871 Longer write-up: https://maskray.me/blog/2021-05-16-elf-interposition-and-bsymbolic If Linux distributions migrate to protected non-vague-linkage external linkage functions by default, the linker option can still be handy because it allows rapid experiment without recompilation. Protected function addresses currently have deep issues in GNU ld. Reviewed By: peter.smith Differential Revision: https://reviews.llvm.org/D102570
2021-07-30 05:46:53 +08:00
callq weak_default@PLT
[ELF][test] Improve -Bsymbolic & -Bsymbolic-functions test Previously there was no test checking that -Bsymbolic-functions only applies to STT_FUNC symbols. Reviewed By: jhenderson Differential Revision: https://reviews.llvm.org/D102461
2021-05-15 00:33:43 +08:00
callq ext_default@PLT
callq notype_default@PLT
callq undef@PLT
.data
.quad data_default
.quad data_protected
.quad data_hidden
.globl data_default, data_protected, data_hidden
.protected data_protected
.hidden data_hidden
.type data_default, @object
.type data_protected, @object
.type data_hidden, @object
data_default: .byte 0
data_protected: .byte 0
data_hidden: .byte 0
#--- b.s
.globl ext_default
.type ext_default,@function
ext_default:
nop