5b9d7a9a64
> Building LLVM 6.0 on FreeBSD/powerpc (devel/llvm60 port) the assertion > in the subject trips (displays twice) when linking libLTO.so.1. The > issue has been filed in FreeBSD's bugzilla, at > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=237068 . It appears > the 'llvm::hashing::detail::get_execution_seed()::seed@@JL_LLVM_6.0' > symbol is being weakly aliased to an indirect symbol > __bss_start@@JL_LLVM_6.0. Since __bss_start@@JL_LLVM_6.0 is an > indirect symbol, it fails the assertion. I haven't looked under a debugger at your testcase but I think I know what is going on here. You have a shared library with a weakly defined llvm::hashing::detail::get_execution_seed()::seed which happens to be at the same location as __bss_start in that library. At the time the linker loads symbols for that library, it sees they are both versioned and thus introduces non-versioned indirect symbols for them. The linker considers the symbols as possibly being aliases, setting up h->u.alias and h->is_weakalias such that __bss_start@@JL_LLVM_6.0 is the definition. No real problem so far, the definition is bfd_link_hash_defined, except that the zero size, no type __bss_start symbol possibly should not be considered an alias in the first place. Later, __bss_start as defined by the linker script is entered into the linker symbol table. This is similar to __bss_start being defined by a regular object file in that ELF symbol resolution rules say that the value of __bss_start in the library is overridden by __bss_start in the executable/library being produced. So to accomplish the override, ld flips __bss_start from being an indirect symbol pointing at __bss_start@@JL_LLVM_6.0 to __bss_start@@JL_LLVM_6.0 being an indirect symbol pointing at __bss_start. That's how we get an unexpected indirect symbol and hit the assert. What should happen I think, is for the def->def_regular code above the assert to run in this case. The symbols are no longer aliases. * elflink.c (_bfd_elf_fix_symbol_flags): If the def for an alias is no longer bfd_link_hash_defined, clear the alias.
README for GNU development tools This directory contains various GNU compilers, assemblers, linkers, debuggers, etc., plus their support routines, definitions, and documentation. If you are receiving this as part of a GDB release, see the file gdb/README. If with a binutils release, see binutils/README; if with a libg++ release, see libg++/README, etc. That'll give you info about this package -- supported targets, how to use it, how to report bugs, etc. It is now possible to automatically configure and build a variety of tools with one command. To build all of the tools contained herein, run the ``configure'' script here, e.g.: ./configure make To install them (by default in /usr/local/bin, /usr/local/lib, etc), then do: make install (If the configure script can't determine your type of computer, give it the name as an argument, for instance ``./configure sun4''. You can use the script ``config.sub'' to test whether a name is recognized; if it is, config.sub translates it to a triplet specifying CPU, vendor, and OS.) If you have more than one compiler on your system, it is often best to explicitly set CC in the environment before running configure, and to also set CC when running make. For example (assuming sh/bash/ksh): CC=gcc ./configure make A similar example using csh: setenv CC gcc ./configure make Much of the code and documentation enclosed is copyright by the Free Software Foundation, Inc. See the file COPYING or COPYING.LIB in the various directories, for a description of the GNU General Public License terms under which you can copy the files. REPORTING BUGS: Again, see gdb/README, binutils/README, etc., for info on where and how to report problems.