Date: Wed, 20 Mar 2019 20:57:38 +0000 From: bugzilla-noreply@freebsd.org To: ports-bugs@FreeBSD.org Subject: [Bug 236062] [exp-run] Against projects/clang800-import branch Message-ID: <bug-236062-7788-4kBMLNLFL5@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-236062-7788@https.bugs.freebsd.org/bugzilla/> References: <bug-236062-7788@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D236062 --- Comment #29 from commit-hook@freebsd.org --- A commit references this bug: Author: dim Date: Wed Mar 20 20:57:13 UTC 2019 New revision: 345349 URL: https://svnweb.freebsd.org/changeset/base/345349 Log: Pull in r352826 from upstream lld trunk (by Fangrui Song): [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=3D6811). 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 Pull in r352943 from upstream lld trunk (by Fangrui Song): [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 =3D> a.so (not linked with -z defs) void f(); // f is undefined void g() { f(); } // b.cc =3D> 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 pro= gram 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 Together, these add support for --no-allow-shlib-undefined, and make it the default for executables, so they will fail to link if any symbols from needed shared libraries are undefined. Reported by: jbeich PR: 236062, 236141 MFC after: 1 month X-MFC-With: r344779 Changes: head/contrib/llvm/tools/lld/ELF/Config.h head/contrib/llvm/tools/lld/ELF/Driver.cpp head/contrib/llvm/tools/lld/ELF/InputFiles.cpp head/contrib/llvm/tools/lld/ELF/InputFiles.h head/contrib/llvm/tools/lld/ELF/Options.td head/contrib/llvm/tools/lld/ELF/SymbolTable.cpp head/contrib/llvm/tools/lld/ELF/SymbolTable.h head/contrib/llvm/tools/lld/ELF/Writer.cpp head/contrib/llvm/tools/lld/docs/ld.lld.1 head/lib/clang/include/lld/Common/Version.inc --=20 You are receiving this mail because: You are on the CC list for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-236062-7788-4kBMLNLFL5>