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/allow-shlib-undefined.s

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

32 lines
1.3 KiB
ArmAsm
Raw Normal View History

[LLD] Mark a number of x86 only tests to require x86 Noticed while testing for an out of tree target. There are probably more tests that should be so marked. I'm not sure who owns these tests so I've added a few names I recognise from the recent history. With advice from probinson, ruiu, rafael and dramatically improved by davidb. Thank you all! Differential Revision: https://reviews.llvm.org/D34685 llvm-svn: 308335
2017-07-19 02:40:50 +08:00
# REQUIRES: x86
[ELF] Support --{,no-}allow-shlib-undefined Summary: In ld.bfd/gold, --no-allow-shlib-undefined is the default when linking an executable. This patch implements a check to error on undefined symbols in a shared object, if all of its DT_NEEDED entries are seen. Our approach resembles the one used in gold, achieves a good balance to be useful but not too smart (ld.bfd traces all DSOs and emulates the behavior of a dynamic linker to catch more cases). The error is issued based on the symbol table, different from undefined reference errors issued for relocations. It is most effective when there are DSOs that were not linked with -z defs (e.g. when static sanitizers runtime is used). gold has a comment that some system libraries on GNU/Linux may have spurious undefined references and thus system libraries should be excluded (https://sourceware.org/bugzilla/show_bug.cgi?id=6811). The story may have changed now but we make --allow-shlib-undefined the default for now. Its interaction with -shared can be discussed in the future. Reviewers: ruiu, grimar, pcc, espindola Reviewed By: ruiu Subscribers: joerg, emaste, arichardson, llvm-commits Differential Revision: https://reviews.llvm.org/D57385 llvm-svn: 352826
2019-02-01 10:25:05 +08:00
# RUN: llvm-mc -filetype=obj -triple=x86_64-unknown-linux %s -o %t.o
[ELF2] Implement --allow-shlib-undefined as default behavior. We ignore --{no,}allow-shlib-undefined options and always allow undefined symbols if we are building a DSO. llvm-svn: 249036
2015-10-02 01:24:24 +08:00
# RUN: llvm-mc -filetype=obj -triple=x86_64-unknown-linux \
[ELF] Support --{,no-}allow-shlib-undefined Summary: In ld.bfd/gold, --no-allow-shlib-undefined is the default when linking an executable. This patch implements a check to error on undefined symbols in a shared object, if all of its DT_NEEDED entries are seen. Our approach resembles the one used in gold, achieves a good balance to be useful but not too smart (ld.bfd traces all DSOs and emulates the behavior of a dynamic linker to catch more cases). The error is issued based on the symbol table, different from undefined reference errors issued for relocations. It is most effective when there are DSOs that were not linked with -z defs (e.g. when static sanitizers runtime is used). gold has a comment that some system libraries on GNU/Linux may have spurious undefined references and thus system libraries should be excluded (https://sourceware.org/bugzilla/show_bug.cgi?id=6811). The story may have changed now but we make --allow-shlib-undefined the default for now. Its interaction with -shared can be discussed in the future. Reviewers: ruiu, grimar, pcc, espindola Reviewed By: ruiu Subscribers: joerg, emaste, arichardson, llvm-commits Differential Revision: https://reviews.llvm.org/D57385 llvm-svn: 352826
2019-02-01 10:25:05 +08:00
# RUN: %p/Inputs/allow-shlib-undefined.s -o %t1.o
# RUN: ld.lld -shared %t1.o -o %t.so
# RUN: ld.lld --allow-shlib-undefined %t.o %t.so -o /dev/null
# RUN: not ld.lld --no-allow-shlib-undefined %t.o %t.so -o /dev/null 2>&1 | FileCheck %s
[ELF] Default to --no-allow-shlib-undefined for executables Summary: This follows the ld.bfd/gold behavior. The error check is useful as it captures a common type of ld.so undefined symbol errors as link-time errors: // a.cc => a.so (not linked with -z defs) void f(); // f is undefined void g() { f(); } // b.cc => executable with a DT_NEEDED entry on a.so void g(); int main() { g(); } // ld.so errors when g() is executed (lazy binding) or when the program is started (-z now) // symbol lookup error: ... undefined symbol: f Reviewers: ruiu, grimar, pcc, espindola Reviewed By: ruiu Subscribers: llvm-commits, emaste, arichardson Tags: #llvm Differential Revision: https://reviews.llvm.org/D57569 llvm-svn: 352943
2019-02-02 08:34:28 +08:00
# Executable defaults to --no-allow-shlib-undefined
# RUN: not ld.lld %t.o %t.so -o /dev/null 2>&1 | FileCheck %s
[ELF] Append " [--no-allow-shlib-undefined]" to the corresponding diagnostics --no-allow-shlib-undefined (enabled by default when linking an executable) rejects unresolved references in shared objects. Users may be confused by the common diagnostics of unresolved symbols in object files (LLD: "undefined symbol: foo"; GNU ld/gold: "undefined reference to") Learn from GCC/clang " [-Wfoo]": append the option name to the diagnostics. Users can find relevant information by searching "--no-allow-shlib-undefined". It should also be obvious to them that the positive form --allow-shlib-undefined can suppress the error. Also downgrade the error to a warning if --noinhibit-exec is used (compatible with GNU ld and gold). Reviewed By: grimar, psmith Differential Revision: https://reviews.llvm.org/D81028
2020-06-03 22:59:28 +08:00
# RUN: ld.lld %t.o %t.so --noinhibit-exec -o /dev/null 2>&1 | FileCheck %s
[ELF] Default to --no-allow-shlib-undefined for executables Summary: This follows the ld.bfd/gold behavior. The error check is useful as it captures a common type of ld.so undefined symbol errors as link-time errors: // a.cc => a.so (not linked with -z defs) void f(); // f is undefined void g() { f(); } // b.cc => executable with a DT_NEEDED entry on a.so void g(); int main() { g(); } // ld.so errors when g() is executed (lazy binding) or when the program is started (-z now) // symbol lookup error: ... undefined symbol: f Reviewers: ruiu, grimar, pcc, espindola Reviewed By: ruiu Subscribers: llvm-commits, emaste, arichardson Tags: #llvm Differential Revision: https://reviews.llvm.org/D57569 llvm-svn: 352943
2019-02-02 08:34:28 +08:00
# -shared defaults to --allow-shlib-undefined
# RUN: ld.lld -shared %t.o %t.so -o /dev/null
[ELF2] Implement --allow-shlib-undefined as default behavior. We ignore --{no,}allow-shlib-undefined options and always allow undefined symbols if we are building a DSO. llvm-svn: 249036
2015-10-02 01:24:24 +08:00
[ELF] Support --{,no-}allow-shlib-undefined Summary: In ld.bfd/gold, --no-allow-shlib-undefined is the default when linking an executable. This patch implements a check to error on undefined symbols in a shared object, if all of its DT_NEEDED entries are seen. Our approach resembles the one used in gold, achieves a good balance to be useful but not too smart (ld.bfd traces all DSOs and emulates the behavior of a dynamic linker to catch more cases). The error is issued based on the symbol table, different from undefined reference errors issued for relocations. It is most effective when there are DSOs that were not linked with -z defs (e.g. when static sanitizers runtime is used). gold has a comment that some system libraries on GNU/Linux may have spurious undefined references and thus system libraries should be excluded (https://sourceware.org/bugzilla/show_bug.cgi?id=6811). The story may have changed now but we make --allow-shlib-undefined the default for now. Its interaction with -shared can be discussed in the future. Reviewers: ruiu, grimar, pcc, espindola Reviewed By: ruiu Subscribers: joerg, emaste, arichardson, llvm-commits Differential Revision: https://reviews.llvm.org/D57385 llvm-svn: 352826
2019-02-01 10:25:05 +08:00
# RUN: echo | llvm-mc -filetype=obj -triple=x86_64-unknown-linux -o %tempty.o
# RUN: ld.lld -shared %tempty.o -o %tempty.so
# RUN: ld.lld -shared %t1.o %tempty.so -o %t2.so
# RUN: ld.lld --no-allow-shlib-undefined %t.o %t2.so -o /dev/null
Remove trailing whitespaces. llvm-svn: 249037
2015-10-02 01:33:36 +08:00
# DSO with undefines:
[ELF2] Implement --allow-shlib-undefined as default behavior. We ignore --{no,}allow-shlib-undefined options and always allow undefined symbols if we are building a DSO. llvm-svn: 249036
2015-10-02 01:24:24 +08:00
# should link with or without any of these options.
[ELF] Support --{,no-}allow-shlib-undefined Summary: In ld.bfd/gold, --no-allow-shlib-undefined is the default when linking an executable. This patch implements a check to error on undefined symbols in a shared object, if all of its DT_NEEDED entries are seen. Our approach resembles the one used in gold, achieves a good balance to be useful but not too smart (ld.bfd traces all DSOs and emulates the behavior of a dynamic linker to catch more cases). The error is issued based on the symbol table, different from undefined reference errors issued for relocations. It is most effective when there are DSOs that were not linked with -z defs (e.g. when static sanitizers runtime is used). gold has a comment that some system libraries on GNU/Linux may have spurious undefined references and thus system libraries should be excluded (https://sourceware.org/bugzilla/show_bug.cgi?id=6811). The story may have changed now but we make --allow-shlib-undefined the default for now. Its interaction with -shared can be discussed in the future. Reviewers: ruiu, grimar, pcc, espindola Reviewed By: ruiu Subscribers: joerg, emaste, arichardson, llvm-commits Differential Revision: https://reviews.llvm.org/D57385 llvm-svn: 352826
2019-02-01 10:25:05 +08:00
# RUN: ld.lld -shared %t1.o -o /dev/null
# RUN: ld.lld -shared --allow-shlib-undefined %t1.o -o /dev/null
# RUN: ld.lld -shared --no-allow-shlib-undefined %t1.o -o /dev/null
[ELF2] Implement --allow-shlib-undefined as default behavior. We ignore --{no,}allow-shlib-undefined options and always allow undefined symbols if we are building a DSO. llvm-svn: 249036
2015-10-02 01:24:24 +08:00
.globl _start
Remove trailing whitespaces. llvm-svn: 249037
2015-10-02 01:33:36 +08:00
_start:
[ELF] - Error out when R_X86_64_PC32/R_X86_64_32 are used against preemptible symbol when linking shared object. When R_X86_64_PC32/R_X86_64_32 relocations are used against preemptible symbol and output is position independent, error should be generated. Differential revision: http://reviews.llvm.org/D18190 llvm-svn: 264707
2016-03-29 16:35:42 +08:00
callq _shared@PLT
[ELF] Support --{,no-}allow-shlib-undefined Summary: In ld.bfd/gold, --no-allow-shlib-undefined is the default when linking an executable. This patch implements a check to error on undefined symbols in a shared object, if all of its DT_NEEDED entries are seen. Our approach resembles the one used in gold, achieves a good balance to be useful but not too smart (ld.bfd traces all DSOs and emulates the behavior of a dynamic linker to catch more cases). The error is issued based on the symbol table, different from undefined reference errors issued for relocations. It is most effective when there are DSOs that were not linked with -z defs (e.g. when static sanitizers runtime is used). gold has a comment that some system libraries on GNU/Linux may have spurious undefined references and thus system libraries should be excluded (https://sourceware.org/bugzilla/show_bug.cgi?id=6811). The story may have changed now but we make --allow-shlib-undefined the default for now. Its interaction with -shared can be discussed in the future. Reviewers: ruiu, grimar, pcc, espindola Reviewed By: ruiu Subscribers: joerg, emaste, arichardson, llvm-commits Differential Revision: https://reviews.llvm.org/D57385 llvm-svn: 352826
2019-02-01 10:25:05 +08:00
[ELF] Append " [--no-allow-shlib-undefined]" to the corresponding diagnostics --no-allow-shlib-undefined (enabled by default when linking an executable) rejects unresolved references in shared objects. Users may be confused by the common diagnostics of unresolved symbols in object files (LLD: "undefined symbol: foo"; GNU ld/gold: "undefined reference to") Learn from GCC/clang " [-Wfoo]": append the option name to the diagnostics. Users can find relevant information by searching "--no-allow-shlib-undefined". It should also be obvious to them that the positive form --allow-shlib-undefined can suppress the error. Also downgrade the error to a warning if --noinhibit-exec is used (compatible with GNU ld and gold). Reviewed By: grimar, psmith Differential Revision: https://reviews.llvm.org/D81028
2020-06-03 22:59:28 +08:00
# CHECK: {{.*}}.so: undefined reference to _unresolved [--no-allow-shlib-undefined]