Date: Mon, 04 May 2020 22:59:52 +0000 From: bugzilla-noreply@freebsd.org To: toolchain@FreeBSD.org Subject: [Bug 230399] devel/libunwind: fails to build with Clang 7 Message-ID: <bug-230399-29464-LpIdTlDFFR@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-230399-29464@https.bugs.freebsd.org/bugzilla/> References: <bug-230399-29464@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=3D230399 --- Comment #13 from commit-hook@freebsd.org --- A commit references this bug: Author: dim Date: Mon May 4 22:59:41 UTC 2020 New revision: 360643 URL: https://svnweb.freebsd.org/changeset/base/360643 Log: Merge additions of LLVM libunwind libgcc_eh and libgcc_s. This is in preparation of further LLVM merges. MFC r307230 (by emaste): Introduce lib/libgcc_eh and lib/libgcc_s for LLVM's implementation They are not yet connected to the build, but I am adding them to allow for easier testing, ports exp-runs, etc. Reviewed by: ed Sponsored by: The FreeBSD Foundation Differential Revision: https://reviews.freebsd.org/D8188 MFC r307231 (by emaste): libgcc_s: add libm dependencies from div{d,s,x}c3 compiler-rt's complex division support routines contain calls to compiler builtins such as `__builtin_scalbnl`. Unfortunately Clang turns these back into a call to `scalbnl`. For now link libm's C version of the required support routines. Reviewed by: ed Sponsored by: The FreeBSD Foundation Differential Revision: https://reviews.freebsd.org/D8190 MFC r307864 (by emaste): Move the LLVM-based libgcc_s to /lib When enabled, it should install in the same location as the existing library. Reported by: antoine MFC r308001 (by emaste): libgcc_eh/libgcc_s: apply hidden visibility only to static libs MFC r308100 (by emaste): compile libunwind c source with -fexceptions When an exception is thrown the unwinder must unwind its own C source (starting with _Unwind_RaiseException in UnwindLevel1.c), so it needs to be built with unwinding data. MFC r308294 (by emaste): libgcc_s: make unspecified shlib symbols local We want only symbols explicitly specified in the Version.map. Sponsored by: The FreeBSD Foundation MFC r308308 (by emaste): Connect new LLVM-based libgcc_eh & libgcc_s to the build Compiler-rt and LLVM's libunwind provide a suitable replacement for libgcc.a, libgcc_eh.a, and libgcc_s.so. Remove the now-unused LLVM_LIBUNWIND block from gnu/lib/libgcc. PR: 213480 [exp-run] Reviewed by: brooks, ed Sponsored by: The FreeBSD Foundation Differential Revision: https://reviews.freebsd.org/D8189 MFC r308379 (by emaste): add __divdi3 and __udivdi3 to libgcc_s symbol version map After r308294 they were missing on i386 (and previously were exported only accidentally). Reported by: antoine MFC r308445 (by emaste): add missing i386 symbols libgcc_s symbol version map After r308294 they were missing on i386 (and previously were exported only accidentally). Reported by: antoine MFC r312076 (by emaste): libgcc_s: add libc DT_NEEDED to fix underlinking PR: 216012 Reported by: jbeich Sponsored by: The FreeBSD Foundation MFC r316101 (by ngie): Apply r315689 to lib/libgcc_s as well to unbreak the gcc xtoolchain build lib/libgcc_s consumes lib/libcompiler_rt/Makefile*. The NO_WERROR.gcc in lib/libcompiler_rt/Makefile doesn't seem to have made a difference in bei= ng able to build this, so sprinkle NO_WERROR.gcc here as well. Reported by: Jenkins (FreeBSD-head-amd64-gcc) Tested with: amd64-gcc-6.3.0 (devel/amd64-xtoolchain-gcc) Sponsored by: Dell EMC Isilon MFC r320673 (by emaste): Sort entries in libgcc_s Version.map MFC r337585 (by dim): In r308100, an explicit -fexceptions flag was added for the C sources from LLVM's libunwind, which end up in libgcc_eh.a and libgcc_s.so. This is because the unwinder needs the unwinder data for its own functions. However, for the C++ sources in libunwind, -fexceptions is already the default, and this can have the side effect of generating a reference to __gxx_personality_v0, the so-called personality function, which is normally provided by the C++ ABI library (libcxxrt or libsupc++). If the reference ends up in the eventual libgcc_s.so, linking any non-C++ programs against it will fail with "undefined reference to `__gxx_personality_v0'". Note that at high optimization levels, the reference is usually optimized away, which is why we have never noticed this problem before. With clang 7.0.0 though, higher optimization levels don't help anymore, since the addition of address-significance tables [1] in <https://reviews.llvm.org/rL337339>. Effectively, this always causes a reference to __gxx_personality_v0. After discussion with the upstream author of that change, it turns out that we should compile libunwind sources with the -fno-exceptions -funwind-tables flags instead. This ensures unwind tables are generated, but no references to any personality functions are emitted. [1] https://lists.llvm.org/pipermail/llvm-dev/2018-May/123514.html Reported by: jbeich PR: 230399 Changes: _U stable/11/ stable/11/Makefile.inc1 stable/11/gnu/lib/Makefile stable/11/gnu/lib/libgcc/Makefile stable/11/lib/Makefile stable/11/lib/libgcc_eh/ stable/11/lib/libgcc_eh/Makefile.inc stable/11/lib/libgcc_s/ stable/11/lib/libgcc_s/Makefile stable/11/lib/libgcc_s/Version.map --=20 You are receiving this mail because: You are the assignee for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-230399-29464-LpIdTlDFFR>