Date: Sun, 19 May 2019 14:43:51 -0700 From: Mark Millard <marklmi@yahoo.com> To: Dimitry Andric <dim@FreeBSD.org> Cc: FreeBSD Toolchain <freebsd-toolchain@freebsd.org>, FreeBSD PowerPC ML <freebsd-ppc@freebsd.org> Subject: Re: FYI: Unable to build -r501994 ports' devel/llvm60 on clang 8 based powerpc64 system: "BFD (GNU Binutils) 2.32 assertion fail elflink.c:2935" Message-ID: <7EB29A62-8C7A-4454-9EEA-22D6C4DD1D24@yahoo.com> In-Reply-To: <F31CDFCD-64B3-41E6-B33C-015F28FA98D6@FreeBSD.org> References: <0743B28F-3F61-401F-BD61-B69C4B207559@yahoo.com> <F31CDFCD-64B3-41E6-B33C-015F28FA98D6@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 2019-May-19, at 11:06, Dimitry Andric <dim at FreeBSD.org> wrote: > On 19 May 2019, at 16:56, Mark Millard via freebsd-toolchain = <freebsd-toolchain at freebsd.org> wrote: >> This was in a poudriere bulk build on a head -r347549 based powerpc64 >> system with system clang 8 for cc and c++ and base/binutils >> for the likes of ld. (The system has the llvm libunwind patches >> for powerpc64 so throwing c++ exceptions work.) >>=20 >> [4397/4552] : && /usr/bin/c++ -fPIC -O2 -pipe -DNDEBUG = -fstack-protector-strong -isystem /usr/local/include = -fno-strict-aliasing -DNDEBUG -isystem /usr/local/include -fPIC = -fvisibility-inlines-hidden -Werror=3Ddate-time = -Werror=3Dunguarded-availability-new -std=3Dc++11 -Wall -W = -Wno-unused-parameter -Wwrite-strings -Wcast-qual = -Wmissing-field-initializers -pedantic -Wno-long-long = -Wcovered-switch-default -Wnon-virtual-dtor -Wdelete-non-virtual-dtor = -Wstring-conversion -fcolor-diagnostics -ffunction-sections = -fdata-sections -O2 -pipe -DNDEBUG -fstack-protector-strong -isystem = /usr/local/include -fno-strict-aliasing -DNDEBUG -isystem = /usr/local/include -fstack-protector-strong -Wl,-z,origin -Wl,-O3 = -Wl,--gc-sections = -Wl,--version-script,/wrkdirs/usr/ports/devel/llvm60/work/.build/tools/lto= /LTO.exports -shared -Wl,-soname,libLTO.so.6 -o lib/libLTO.so.6.0.1 = tools/lto/CMakeFiles/LTO.dir/LTODisassembler.cpp.o = tools/lto/CMakeFiles/LTO.dir/lto.cpp.o -L/usr/local/lib = -Wl,-rpath,"\$ORIGIN/../ >> lib:/usr/local/lib" lib/libLLVM-6.0.so && : >> FAILED: lib/libLTO.so.6.0.1 >> : && /usr/bin/c++ -fPIC -O2 -pipe -DNDEBUG -fstack-protector-strong = -isystem /usr/local/include -fno-strict-aliasing -DNDEBUG -isystem = /usr/local/include -fPIC -fvisibility-inlines-hidden -Werror=3Ddate-time = -Werror=3Dunguarded-availability-new -std=3Dc++11 -Wall -W = -Wno-unused-parameter -Wwrite-strings -Wcast-qual = -Wmissing-field-initializers -pedantic -Wno-long-long = -Wcovered-switch-default -Wnon-virtual-dtor -Wdelete-non-virtual-dtor = -Wstring-conversion -fcolor-diagnostics -ffunction-sections = -fdata-sections -O2 -pipe -DNDEBUG -fstack-protector-strong -isystem = /usr/local/include -fno-strict-aliasing -DNDEBUG -isystem = /usr/local/include -fstack-protector-strong -Wl,-z,origin -Wl,-O3 = -Wl,--gc-sections = -Wl,--version-script,/wrkdirs/usr/ports/devel/llvm60/work/.build/tools/lto= /LTO.exports -shared -Wl,-soname,libLTO.so.6 -o lib/libLTO.so.6.0.1 = tools/lto/CMakeFiles/LTO.dir/LTODisassembler.cpp.o = tools/lto/CMakeFiles/LTO.dir/lto.cpp.o -L/usr/local/lib = -Wl,-rpath,"\$ORIGIN/../lib:/usr/loc >> al/lib" lib/libLLVM-6.0.so && : >> /usr/bin/powerpc64-unknown-freebsd13.0-ld: BFD (GNU Binutils) 2.32 = assertion fail elflink.c:2935 >> /usr/bin/powerpc64-unknown-freebsd13.0-ld: BFD (GNU Binutils) 2.32 = assertion fail elflink.c:2935 >=20 > See <https://bugs.freebsd.org/237068>. I think this is a BFD ld bug, > but I still haven't been able to come up with a small test case. Any > help appreciated. :-) I've put the evidence leading to the following in the bugzilla report. The problem is tied to "seed" in: = /wrkdirs/usr/ports/devel/llvm60/work/llvm-6.0.1.src/include/llvm/ADT/Hashi= ng.h 's: . . . namespace llvm { . . . // All of the implementation details of actually computing the various = hash // code values are held within this namespace. These routines are = included in // the header file mainly to allow inlining and constant propagation. namespace hashing { namespace detail { . . . /// \brief A global, fixed seed-override variable. /// /// This variable can be set using the \see = llvm::set_fixed_execution_seed /// function. See that function for details. Do not, under any = circumstances, /// set or read this variable. extern size_t fixed_seed_override; inline size_t get_execution_seed() { // FIXME: This needs to be a per-execution seed. This is just a = placeholder // implementation. Switching to a per-execution seed is likely to = flush out // instability bugs and so will happen as its own commit. // // However, if there is a fixed seed override set the first time this = is // called, return that instead of the per-execution seed. const uint64_t seed_prime =3D 0xff51afd7ed558ccdULL; static size_t seed =3D fixed_seed_override ? fixed_seed_override : (size_t)seed_prime; return seed; } It ends up with *h in the reported BFD_ASSERT failures having: _ZZN4llvm7hashing6detail18get_execution_seedEvE4seed@@LLVM_6.0 root.type =3D bfd_link_hash_defweak is_weakalias =3D 1 And *h->u.alias having: __bss_start@@LLVM_6.0 root.type =3D bfd_link_hash_indirect is_weakalias =3D 0 That means in the BFD_ASSERT: def->root.type=3D=3Dbfd_link_hash_indirect which fails the assert's: def->root.type =3D=3D bfd_link_hash_defined =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?7EB29A62-8C7A-4454-9EEA-22D6C4DD1D24>