Created attachment 189675 [details] Revert r327910, reapply WITH_LLD_BOOTSTRAP for i386 Regressions reported in i386 ports with WITH_LLD_BOOTSTRAP, reverted in r327910.
Some failures on i386 (incomplete list, this is with only 5000 ports built): http://package23.nyi.freebsd.org/data/headi386-default-PR222735PR224957/2018-01-12_22h10m45s/logs/errors/leatherman-1.3.0_3.log http://package23.nyi.freebsd.org/data/headi386-default-PR222735PR224957/2018-01-12_22h10m45s/logs/errors/rubygem-concurrent-ruby-ext-1.0.5.log http://package23.nyi.freebsd.org/data/headi386-default-PR222735PR224957/2018-01-12_22h10m45s/logs/errors/rubygem-hamster-3.0.0.log http://package23.nyi.freebsd.org/data/headi386-default-PR222735PR224957/2018-01-12_22h10m45s/logs/errors/rubygem-i18n-0.9.1,2.log On amd64, I noticed 1 new failure: http://beefy12.nyi.freebsd.org/data/head-amd64-default/p458707_s327803/logs/errors/leatherman-1.3.0_3.log
Antoine, I could build devel/leatherman on head-amd64, I can't access beefy12.nyi.freebsd.org to review the logfiles: https://krion.cc/data/12amd64-default/2018-01-13_11h46m54s/logs/leatherman-1.3.0_3.log
New logfile URL: https://krion.cc/data/head-amd64-default/2018-01-13_11h46m54s/logs/leatherman-1.3.0_3.log
(In reply to Kirill Ponomarev from comment #2) I can reproduce the failure on another builder: http://package22.nyi.freebsd.org/data/headamd64-default-PR222735PR224957/2018-01-13_06h46m36s/logs/errors/leatherman-1.3.0_3.log Note that this is with WITH_LLD_BOOSTRAP, and WITHOUT_LLD_IS_LD
New failures on i386 (with llvm 5): + {"origin"=>"devel/leatherman", "phase"=>"build", "errortype"=>"linker_error"} + {"origin"=>"devel/rubygem-concurrent-ruby-edge", "phase"=>"stage", "errortype"=>"???"} + {"origin"=>"devel/rubygem-concurrent-ruby-ext", "phase"=>"stage", "errortype"=>"???"} + {"origin"=>"devel/rubygem-hamster", "phase"=>"stage", "errortype"=>"???"} + {"origin"=>"devel/rubygem-i18n", "phase"=>"stage", "errortype"=>"???"} + {"origin"=>"lang/nhc98", "phase"=>"build", "errortype"=>"???"} + {"origin"=>"math/R-cran-recipes", "phase"=>"stage", "errortype"=>"coredump"} + {"origin"=>"news/nntpcache", "phase"=>"build", "errortype"=>"coredump"} + {"origin"=>"print/pdftk", "phase"=>"build", "errortype"=>"missing_header"} New failure logs on i386 (with llvm 5): http://package23.nyi.freebsd.org/data/headi386-default-PR222735PR224957/2018-01-12_22h10m45s/logs/errors/leatherman-1.3.0_3.log http://package23.nyi.freebsd.org/data/headi386-default-PR222735PR224957/2018-01-12_22h10m45s/logs/errors/rubygem-concurrent-ruby-edge-0.3.1.log http://package23.nyi.freebsd.org/data/headi386-default-PR222735PR224957/2018-01-12_22h10m45s/logs/errors/rubygem-concurrent-ruby-ext-1.0.5.log http://package23.nyi.freebsd.org/data/headi386-default-PR222735PR224957/2018-01-12_22h10m45s/logs/errors/rubygem-hamster-3.0.0.log http://package23.nyi.freebsd.org/data/headi386-default-PR222735PR224957/2018-01-12_22h10m45s/logs/errors/rubygem-i18n-0.9.1,2.log http://package23.nyi.freebsd.org/data/headi386-default-PR222735PR224957/2018-01-12_22h10m45s/logs/errors/nhc98-1.22_3.log http://package23.nyi.freebsd.org/data/headi386-default-PR222735PR224957/2018-01-12_22h10m45s/logs/errors/R-cran-recipes-0.1.0.log http://package23.nyi.freebsd.org/data/headi386-default-PR222735PR224957/2018-01-12_22h10m45s/logs/errors/nntpcache-3.0.2_10.log http://package23.nyi.freebsd.org/data/headi386-default-PR222735PR224957/2018-01-12_22h10m45s/logs/errors/pdftk-2.02_6.log
Leatherman failure (same as on amd64): : && /usr/bin/c++ -O2 -pipe -fstack-protector -fno-strict-aliasing -O2 -pipe -fstack-protector -fno-strict-aliasing -fstack-protector tests/CMakeFiles/leatherman_test.dir/main.cc.o tests/CMakeFiles/leatherman_test.dir/__/util/tests/scoped_env.cc.o tests/CMakeFiles/leatherman_test.dir/__/util/tests/strings_test.cc.o tests/CMakeFiles/leatherman_test.dir/__/util/tests/option_set.cc.o tests/CMakeFiles/leatherman_test.dir/__/util/tests/environment.cc.o tests/CMakeFiles/leatherman_test.dir/__/util/tests/timer.cc.o tests/CMakeFiles/leatherman_test.dir/__/util/tests/uri.cc.o tests/CMakeFiles/leatherman_test.dir/__/util/tests/posix/environment.cc.o tests/CMakeFiles/leatherman_test.dir/__/locale/tests/locale.cc.o tests/CMakeFiles/leatherman_test.dir/__/locale/tests/format.cc.o tests/CMakeFiles/leatherman_test.dir/__/logging/tests/logging.cc.o tests/CMakeFiles/leatherman_test.dir/__/logging/tests/logging_stream.cc.o tests/CMakeFiles/leatherman_test.dir/__/logging/tests/logging_stream_lines.cc.o tests/CMakeFiles/leatherman_test.dir/__/logging/tests/logging_on_message.cc.o tests/CMakeFiles/leatherman_test.dir/__/logging/tests/posix/logging.cc.o tests/CMakeFiles/leatherman_test.dir/__/logging/tests/logging_i18n.cc.o tests/CMakeFiles/leatherman_test.dir/__/json_container/tests/json_container_test.cc.o tests/CMakeFiles/leatherman_test.dir/__/file_util/tests/file_utils_test.cc.o tests/CMakeFiles/leatherman_test.dir/__/file_util/tests/directory_utils_test.cc.o tests/CMakeFiles/leatherman_test.dir/__/file_util/tests/fixtures.cc.o tests/CMakeFiles/leatherman_test.dir/__/curl/tests/client_test.cc.o tests/CMakeFiles/leatherman_test.dir/__/curl/tests/request_test.cc.o tests/CMakeFiles/leatherman_test.dir/__/curl/tests/response_test.cc.o tests/CMakeFiles/leatherman_test.dir/__/dynamic_library/tests/dynamic_library_tests.cc.o tests/CMakeFiles/leatherman_test.dir/__/execution/tests/log_capture.cc.o tests/CMakeFiles/leatherman_test.dir/__/execution/tests/posix/execution.cc.o tests/CMakeFiles/leatherman_test.dir/__/ruby/tests/api-test.cc.o -o bin/leatherman_test -Wl,-rpath,/usr/local/lib:/wrkdirs/usr/ports/devel/leatherman/work/.build/lib /usr/local/lib/libboost_date_time.so /usr/local/lib/libboost_chrono.so /usr/local/lib/libboost_system.so /usr/local/lib/libboost_locale.so /usr/local/lib/libboost_log.so /usr/local/lib/libboost_log_setup.so /usr/local/lib/libboost_thread.so /usr/local/lib/libboost_filesystem.so /usr/local/lib/libboost_regex.so /usr/local/lib/libboost_atomic.so -pthread lib/libleatherman_ruby.so.1.3.0 lib/libleatherman_execution.so.1.3.0 lib/libleatherman_dynamic_library.so.1.3.0 lib/libleatherman_curl.so.1.3.0 lib/libleatherman_file_util.so.1.3.0 lib/libleatherman_json_container.so.1.3.0 lib/libleatherman_logging.so.1.3.0 lib/libleatherman_locale.so.1.3.0 lib/libleatherman_util.so.1.3.0 lib/libmock_curl.so && : /usr/local/lib/libboost_log_setup.so: undefined reference to `_ZTIDi' /usr/local/lib/libboost_log_setup.so: undefined reference to `_ZTIDs' c++: error: linker command failed with exit code 1 (use -v to see invocation) Ruby failures are of the form (cd /wrkdirs/usr/ports/devel/rubygem-concurrent-ruby-edge/work/concurrent-ruby-edge-0.3.1; /usr/bin/env RB_USER_INSTALL=yes LANG=en_US.UTF-8 LC_ALL=en_US.UTF-8 /usr/local/bin/gem24 install -l --no-update-sources --install-dir /wrkdirs/usr/ports/devel/rubygem-concurrent-ruby-edge/work/stage/usr/local/lib/ruby/gems/2.4 --ignore-dependencies --bindir=/wrkdirs/usr/ports/devel/rubygem-concurrent-ruby-edge/work/stage/usr/local/bin --rdoc --ri concurrent-ruby-edge-0.3.1.gem -- --build-args ) /usr/local/lib/ruby/site_ruby/2.4/rubygems/core_ext/kernel_require.rb:59: [BUG] rb_gc_mark(): 0x281eb75c is T_NONE nhc98: sh /wrkdirs/usr/ports/lang/nhc98/work/nhc98-1.22/targets/ix86-FreeBSD/hmake3.config Not enough memory for heap and stack. Not enough memory for heap and stack. Not enough memory for heap and stack. R-cran-recipes: ** testing if installed package can be loaded * DONE (recipes) Floating point exception (core dumped) nntpcache: ../confused/confused ../cf/nnconf.cf gmake[5]: *** [Makefile:709: nnconf.h] Segmentation fault (core dumped) pdftk: gmake[2]: Entering directory '/wrkdirs/usr/ports/print/pdftk/work/pdftk-2.02-dist/java' /usr/local/bin/gcj6 -L/usr/local/lib -fstack-protector -Wl,-rpath=/usr/local/lib/gcc6 -L/usr/local/lib/gcc6 -w -Wall -Wextra -fsource=1.3 -O2 --encoding=UTF-8 --classpath=":/wrkdirs/usr/ports/print/pdftk/work/pdftk-2.02-dist/java:." -C pdftk/com/lowagie/text/ElementTags.java gcj6: internal compiler error: Segmentation fault (program ecj1) Please submit a full bug report, with preprocessed source if appropriate. See <http://gcc.gnu.org/bugs.html> for instructions. gmake[2]: [Makefile:44: pdftk/com/lowagie/text/ElementTags.class] Error 4 (ignored)
Is someone working on fixing lld to not link libgcc_s in all libs on amd64? I think it is a blocker for WITH_LLD_BOOSTRAP on amd64 too.
(In reply to Antoine Brodin from comment #7) > Is someone working on fixing lld to not link libgcc_s in all libs on amd64? Can you add more detail? I believe that as of the Clang 6 migration libm has gained a dependency on libgcc_s. I am not aware of other issues.
(In reply to Ed Maste from comment #8) For clarity, the libm-libgcc_s dependency is an issue, but one of Clang 6. I am not aware of issues relating specifically to libgcc_s and lld.
(In reply to Ed Maste from comment #9) Or, it may be a regression from lld 5 to lld 6.
This is a regression from lld 5 to lld 6, almost all libs are now linked to libgcc_s : % readelf -d libcrypt.so.5 | grep libgcc_s 0x0000000000000001 NEEDED Shared library: [libgcc_s.so.1] % readelf -d libm.so.5 | grep libgcc_s 0x0000000000000001 NEEDED Shared library: [libgcc_s.so.1] % readelf -d libsbuf.so.6 | grep libgcc_s 0x0000000000000001 NEEDED Shared library: [libgcc_s.so.1] % readelf -d libz.so.6 | grep libgcc_s 0x0000000000000001 NEEDED Shared library: [libgcc_s.so.1] etc.
(In reply to Antoine Brodin from comment #7) > Is someone working on fixing lld to not link libgcc_s in all libs on amd64? > > I think it is a blocker for WITH_LLD_BOOSTRAP on amd64 too. This seems to be a regression between 5.0.0 and 6.0.0. I'm bisecting.
Dimitry found the responsible lld change and submitted https://bugs.llvm.org/show_bug.cgi?id=36029
Maybe LLD_BOOTSTRAP should be temporarily disabled for amd64. Workarounds for libgcc_s and libcxxrt issues shouldn't land in ports unlike LLD_UNSAFE.
Could LLD_BOOTSTRAP be reverted on amd64 if there is no pending fix?
Update in LLVM PR 36029 as of this morning Rafael is investigating. I'm hopeful there will be a patch in short order (e.g., today); if a patch is not forthcoming we can revert.
The lld DT_NEEDED issue should be fixed as of r328286.
Some symbols that used to be in some libs seem to be no longer there with LLD_BOOTSTRAP An example is the following symbols in libcxxrt.so : _ZTIDh _ZTIDi _ZTIDn _ZTIDs (there are more)
> Some symbols that used to be in some libs seem to be no longer there with > LLD_BOOTSTRAP > > An example is the following symbols in libcxxrt.so : > _ZTIDh _ZTIDi _ZTIDn _ZTIDs (there are more) I believe this is a bug in libcxxrt's Version.map, related to the symbols added in r260553 to address PR 185663. Antoine, did you find any other examples of this issue? In my search I only found the offending construct in libcxxrt's Version.map.
A commit references this bug: Author: emaste Date: Tue Jan 23 22:41:14 UTC 2018 New revision: 328305 URL: https://svnweb.freebsd.org/changeset/base/328305 Log: libcxxrt: Move mangled symbols out of extern "C++" in Version.map r260553 added a number of mangled C++ symbols to Version.map inside of an existing `extern "C++"` block. ld.bfd 2.17.50 treats `extern "C++"` permissively and will match both mangled and demangled symbols against the strings in the version map block. ld.lld interprets `extern "C++"` strictly, and matches only demangled symbols. I believe lld's behaviour is correct. Contemporary versions of ld.bfd also behave as lld does, so move the mangled symbols out of the `extern "C++"` block. PR: 225128, 185663 MFC after: 1 week Sponsored by: The FreeBSD Foundation Changes: head/lib/libcxxrt/Version.map
A commit references this bug: Author: emaste Date: Tue Jan 30 01:13:06 UTC 2018 New revision: 328583 URL: https://svnweb.freebsd.org/changeset/base/328583 Log: MFC r328305: libcxxrt: Move mangled symbols out of extern "C++" in Version.map r260553 added a number of mangled C++ symbols to Version.map inside of an existing `extern "C++"` block. ld.bfd 2.17.50 treats `extern "C++"` permissively and will match both mangled and demangled symbols against the strings in the version map block. ld.lld interprets `extern "C++"` strictly, and matches only demangled symbols. I believe lld's behaviour is correct. Contemporary versions of ld.bfd also behave as lld does, so move the mangled symbols out of the `extern "C++"` block. PR: 225128, 185663 Sponsored by: The FreeBSD Foundation Changes: _U stable/11/ stable/11/lib/libcxxrt/Version.map
Now that libcxxrt's Version.map is fixed in FreeBSD and we've imported the lld fixes for the DT_NEEDED issue I think we're ready for another exp-run. The failures other than leatherman are quite strange so I'm hopeful we can confirm they still exist and generate reproduction cases for lld developers.
On i386, I see 3 new failures with LLD_BOOTSTRAP: + {"origin"=>"lang/nhc98", "phase"=>"build", "errortype"=>"???"} + {"origin"=>"news/nntpcache", "phase"=>"build", "errortype"=>"coredump"} + {"origin"=>"print/pdftk", "phase"=>"build", "errortype"=>"missing_header"} Failure logs: http://package23.nyi.freebsd.org/data/headi386gnucxx98lldb-default/2018-02-04_06h29m05s/logs/errors/nhc98-1.22_3.log http://package23.nyi.freebsd.org/data/headi386gnucxx98lldb-default/2018-02-04_06h29m05s/logs/errors/nntpcache-3.0.2_10.log http://package23.nyi.freebsd.org/data/headi386gnucxx98lldb-default/2018-02-04_06h29m05s/logs/errors/pdftk-2.02_6.log
log excerpts: *** lang/nhc98 sh /wrkdirs/usr/ports/lang/nhc98/work/nhc98-1.22/targets/ix86-FreeBSD/hmake3.config Not enough memory for heap and stack. Not enough memory for heap and stack. Not enough memory for heap and stack. gmake[2]: *** [Makefile:63: config] Error 255 *** news/nntpcache ../confused/confused ../cf/nnconf.cf gmake[5]: *** [Makefile:709: nnconf.h] Segmentation fault (core dumped) *** print/pdftk ===> Building for pdftk-2.02_6 gmake[1]: Entering directory '/wrkdirs/usr/ports/print/pdftk/work/pdftk-2.02-dist/pdftk' gmake -f Makefile -iC /wrkdirs/usr/ports/print/pdftk/work/pdftk-2.02-dist/pdftk/../java all gmake[2]: Entering directory '/wrkdirs/usr/ports/print/pdftk/work/pdftk-2.02-dist/java' /usr/local/bin/gcj6 -L/usr/local/lib -fstack-protector -Wl,-rpath=/usr/local/lib/gcc6 -L/usr/local/lib/gcc6 -w -Wall -Wextra -fsource=1.3 -O2 --encoding=UTF-8 --classpath=":/wrkdirs/usr/ports/print/pdftk/work/pdftk-2.02-dist/java:." -C pdftk/com/lowagie/text/ElementTags.java gcj6: internal compiler error: Segmentation fault (program ecj1) Please submit a full bug report, with preprocessed source if appropriate. See <http://gcc.gnu.org/bugs.html> for instructions. gmake[2]: [Makefile:44: pdftk/com/lowagie/text/ElementTags.class] Error 4 (ignored)
(In reply to Antoine Brodin from comment #23) I partially diagnosed the issue with nntpcache (which also seems to occur on amd64). The issue is around the _end symbol, which marks the end of the .bss section. When libc.so is linked with GNU ld, the _end symbol's section index is SHN_ABS (i.e., the symbol value is not affected by relocations). When it's linked with lld, _end's section index is that of .bss. When linking an executable against an lld-linked libc.so, GNU ld does not include _end in the executable's dynamic symbol table. The crash then occurs because the executable uses sbrk(3), curbrk is initialized to &_end, and because the executable does not export _end, libc initializes curbrk to the address of its own internal _end symbol, which is wrong. The problem occurs when linking an executable with ld from binutils 2.30 as well. I hacked lld to emit _end with a shndx of SHN_ABS, and when using a libc compiled with that hack I can compile news/nntpcache. I have not been able to reproduce the other build failures so far. I'm having trouble figuring out why GNU ld refuses to emit _end in this scenario. _end is synthesized using the system linker scripts, and I haven't been able to figure out exactly what logic is causing it to be excluded. It seems incorrect that GNU ld using SHN_ABS this way in the first place: obviously the value of _end is going to be modified by a relocation when libc.so is loaded.
I'd like to request another exp-run of this change.
Main PR 214864 also updated with patch to enable both LLD options (LLD_BOOTSTRAP and LLD_IS_LD) for i386.
I have a problem, it seems WITH_LLD_BOOTSTRAP implies LLD_IS_LD ...
(In reply to Antoine Brodin from comment #28) scratch this, i'm building for amd64 instead of i386
LLD_BOOTSTRAP breaks gnu ld on i386: USER PID %CPU %MEM VSZ RSS TT STAT STARTED TIME COMMAND root 202 100.0 0.0 55704 54816 2 R+J 19:10 37:24.16 /usr/bin/ld --eh-frame-hdr -dynamic-linker /libexec/ld-elf.so.1 --hash-style=both --enable-new-dtags -m elf_i386_fbsd -o a.out /usr/lib/crt1.o /usr/lib/crti.o /usr/lib/crtbegin.o -L/usr/lib -Bsymbolic-functions --library=c++ --library=m --library=gcc --as-needed --library=gcc_s --no-as-needed --library=c --library=gcc --as-needed --library=gcc_s --no-as-needed /usr/lib/crtend.o /usr/lib/crtn.o root 26276 100.0 0.1 77840 73876 2 R+J 18:30 75:17.29 /usr/bin/ld --eh-frame-hdr -dynamic-linker /libexec/ld-elf.so.1 --hash-style=both --enable-new-dtags -m elf_i386_fbsd -o a.out /usr/lib/crt1.o /usr/lib/crti.o /usr/lib/crtbegin.o -L/usr/lib -Bsymbolic-functions --library=c++ --library=m --library=gcc --as-needed --library=gcc_s --no-as-needed --library=c --library=gcc --as-needed --library=gcc_s --no-as-needed /usr/lib/crtend.o /usr/lib/crtn.o root 92322 100.0 0.1 91180 87708 2 R+J 17:57 108:55.45 /usr/bin/ld --eh-frame-hdr -dynamic-linker /libexec/ld-elf.so.1 --hash-style=both --enable-new-dtags -m elf_i386_fbsd -o libconftest.so /usr/lib/crt1.o /usr/lib/crti.o /usr/lib/crtbegin.o -L/usr/lib conftest2.o --library=c++ --library=m --library=gcc --as-needed --library=gcc_s --no-as-needed --library=c --library=gcc --as-needed --library=gcc_s --no-as-needed /usr/lib/crtend.o /usr/lib/crtn.o root 73081 99.6 0.1 73132 68940 2 R+J 18:40 66:25.88 /usr/bin/ld --eh-frame-hdr -dynamic-linker /libexec/ld-elf.so.1 --hash-style=both --enable-new-dtags -m elf_i386_fbsd -o a.out /usr/lib/crt1.o /usr/lib/crti.o /usr/lib/crtbegin.o -L/usr/lib /tmp/conftest-3351e0.o --library=gcc --as-needed --library=gcc_s --no-as-needed --library=c --library=gcc --as-needed --library=gcc_s --no-as-needed /usr/lib/crtend.o /usr/lib/crtn.o
(In reply to Antoine Brodin from comment #30) What are you building when that occurs?
(In reply to Mark Johnston from comment #31) It's often happens during configure step, for instance when configuring math/gmp checking compiler cc -O2 -pipe -fstack-protector -fno-strict-aliasing ... => gnu ld spins
(In reply to Antoine Brodin from comment #32) Thanks. That gives an easy test case that I can reproduce on an lld-linked world: markj@pesky> uname -m i386 markj@pesky> cat conftest.c int k; int foo () { __builtin_alloca (k); } markj@pesky> ld --version GNU ld 2.17.50 [FreeBSD] 2007-07-03 Copyright 2007 Free Software Foundation, Inc. This program is free software; you may redistribute it under the terms of the GNU General Public License. This program has absolutely no warranty. markj@pesky> clang conftest.c conftest.c:1:43: warning: control reaches end of non-void function [-Wreturn-type] int k; int foo () { __builtin_alloca (k); } ^ 1 warning generated. <hang>
The issue arises with the objects built from lib/csu. If they're linked by ld.bfd instead, the hang doesn't occur. If I use binutils 2.30 to link conftest.c, I get an interesting warning: markj@pesky> clang conftest.c conftest.c:1:43: warning: control reaches end of non-void function [-Wreturn-type] int k; int foo () { __builtin_alloca (k); } ^ 1 warning generated. /usr/bin/ld: Dwarf Error: Line info data is bigger (0xefb0101) than the space remaining in the section (0x23f) /usr/lib/crt1.o: In function `_start1': (.text+0xa0): undefined reference to `main' clang: error: linker command failed with exit code 1 (use -v to see invocation) ld from binutils 2.18.5 is spinning with this stack: (gdb) bt #0 0x000d0c1c in add_line_info (table=0x207d4548, address=<optimized out>, filename=0x201a80c0 "\001/usr/home/markj/src/freebsd-dev/lib/csu/i386", line=1, column=0, end_sequence=0) at /usr/home/markj/src/freebsd-dev/gnu/usr.bin/binutils/libbfd/../../../../contrib/binutils/bfd/dwarf2.c:849 #1 0x000cfd1e in decode_line_info (unit=<optimized out>, stash=<optimized out>) at /usr/home/markj/src/freebsd-dev/gnu/usr.bin/binutils/libbfd/../../../../contrib/binutils/bfd/dwarf2.c:1169 #2 0x000cf693 in comp_unit_find_nearest_line (unit=0x207d44bc, addr=<optimized out>, filename_ptr=0xffbfe5d0, functionname_ptr=0xffbfe5cc, linenumber_ptr=0xffbfe5c8, stash=0x20469e30) at /usr/home/markj/src/freebsd-dev/gnu/usr.bin/binutils/libbfd/../../../../contrib/binutils/bfd/dwarf2.c:2103 #3 0x000ced29 in find_line (abfd=0x201d50c0, section=<optimized out>, offset=160, symbol=0x0, symbols=0x20480000, filename_ptr=0xffbfe5d0, functionname_ptr=0xffbfe5cc, linenumber_ptr=0xffbfe5c8, addr_size=0, pinfo=0x20197344) at /usr/home/markj/src/freebsd-dev/gnu/usr.bin/binutils/libbfd/../../../../contrib/binutils/bfd/dwarf2.c:2575 #4 0x000ce063 in _bfd_dwarf2_find_nearest_line (abfd=0x201d50c0, section=0x201990d0, symbols=0x20480000, offset=160, filename_ptr=0xffbfe5d0, functionname_ptr=0xffbfe5cc, linenumber_ptr=0xffbfe5c8, addr_size=0, pinfo=0x20197344) at /usr/home/markj/src/freebsd-dev/gnu/usr.bin/binutils/libbfd/../../../../contrib/binutils/bfd/dwarf2.c:2607 #5 0x000ac37e in _bfd_elf_find_nearest_line (abfd=0x201d50c0, section=0x201990d0, symbols=0x20480000, offset=160, filename_ptr=0xffbfe5d0, functionname_ptr=0xffbfe5cc, line_ptr=0xffbfe5c8) at /usr/home/markj/src/freebsd-dev/gnu/usr.bin/binutils/libbfd/../../../../contrib/binutils/bfd/elf.c:7198 #6 0x0007c3a9 in vfinfo (fp=0x181bac <__sF+472>, fmt=0x250e8 " undefined reference to `%T'\n", arg=0xffbfe668 "\300P\035 \320\220\031 \240", is_warning=1) at /usr/home/markj/src/freebsd-dev/gnu/usr.bin/binutils/ld/../../../../contrib/binutils/ld/ldmisc.c:324 #7 0x0007c82d in einfo (fmt=0x250e3 "%X%C: undefined reference to `%T'\n") at /usr/home/markj/src/freebsd-dev/gnu/usr.bin/binutils/ld/../../../../contrib/binutils/ld/ldmisc.c:465 #8 0x0007b838 in undefined_symbol (info=0x1831d0 <link_info>, name=0x201bf6c8 "main", abfd=0x201d50c0, section=0x201990d0, address=160, error=1) at /usr/home/markj/src/freebsd-dev/gnu/usr.bin/binutils/ld/../../../../contrib/binutils/ld/ldmain.c:1397 #9 0x0008f1d6 in elf_i386_relocate_section (output_bfd=0x201d5000, info=0x1831d0 <link_info>, input_bfd=0x201d50c0, input_section=0x201990d0, contents=0x206d5000 "1\355U\211\345\203\344\360\215E\b\203\354\004P\377u\004R\350\b", relocs=0x201d8288, local_syms=0x2046be00, local_sections=0x201ff400) at /usr/home/markj/src/freebsd-dev/gnu/usr.bin/binutils/libbfd/../../../../contrib/binutils/bfd/elf32-i386.c:2346 #10 0x000bb38d in elf_link_input_bfd (input_bfd=<optimized out>, finfo=<optimized out>) at /usr/home/markj/src/freebsd-dev/gnu/usr.bin/binutils/libbfd/../../../../contrib/binutils/bfd/elflink.c:8706 #11 bfd_elf_final_link (abfd=0x201d5000, info=0x1831d0 <link_info>) at /usr/home/markj/src/freebsd-dev/gnu/usr.bin/binutils/libbfd/../../../../contrib/binutils/bfd/elflink.c:9843 #12 0x0007cf35 in ldwrite () at /usr/home/markj/src/freebsd-dev/gnu/usr.bin/binutils/ld/../../../../contrib/binutils/ld/ldwrite.c:557 #13 0x0007a728 in main (argc=<optimized out>, argv=<optimized out>) at /usr/home/markj/src/freebsd-dev/gnu/usr.bin/binutils/ld/../../../../contrib/binutils/ld/ldmain.c:468
A commit references this bug: Author: emaste Date: Tue Jul 24 11:35:23 UTC 2018 New revision: 336664 URL: https://svnweb.freebsd.org/changeset/base/336664 Log: lld: fix addends with partial linking [ELF] Update addends in non-allocatable sections for REL targets when creating a relocatable output. LLVM PR: 37735 LLVM Differential Revision: https://reviews.llvm.org/D48929 PR: 225128 Obtained from: LLVM r336799 by Igor Kudrin Changes: head/contrib/llvm/tools/lld/ELF/InputSection.cpp
I think the issues tracked in PR228574 and PR228753 should now be fixed, and we should be ready for another exp-run.
ok, I will test once head is unbroken...
https://ci.freebsd.org/tinderbox/ shows HEAD all green except riscv64; what is the issue?
(In reply to Ed Maste from comment #38) Presumably https://lists.freebsd.org/pipermail/svn-src-all/2018-July/167754.html
(In reply to Mark Johnston from comment #39) Ah, indeed, now fixed by r336693.
A commit references this bug: Author: emaste Date: Mon Jul 30 00:08:36 UTC 2018 New revision: 336880 URL: https://svnweb.freebsd.org/changeset/base/336880 Log: MFC r336664: lld: fix addends with partial linking [ELF] Update addends in non-allocatable sections for REL targets when creating a relocatable output. LLVM PR: 37735 LLVM Differential Revision: https://reviews.llvm.org/D48929 PR: 225128, 228753 Obtained from: LLVM r336799 by Igor Kudrin Changes: _U stable/11/ stable/11/contrib/llvm/tools/lld/ELF/InputSection.cpp
Exp-run looks fine.
A commit references this bug: Author: emaste Date: Mon Jul 30 12:38:08 UTC 2018 New revision: 336901 URL: https://svnweb.freebsd.org/changeset/base/336901 Log: Enable ld.lld as bootstrap linker by default on i386 Akin to r327783 for amd64. lld has been usable for amd64 for quite some time, but a couple of issues remained that affected i386. These were recently addressed upstream in lld and merged into FreeBSD or addressed directly in FreeBSD (r326831, r326879, r326897, r326957, r333401, r334626, r336664). Similarly to the intial amd64 commit this change enables lld only as the bootstrap linker (used to link the kernel and userland libraries and executables), while GNU ld.bfd is still installed as /usr/bin/ld and used for ports builds. That will be changed shortly, after an exp-run. This is a recommit of r327823 after additional lld fixes. PR: 225128 (exp-run) Relnotes: Yes Sponsored by: The FreeBSD Foundation Changes: head/share/mk/src.opts.mk
Thank you for the exp-run. exp-run for LLD_IS_LD on i386 is in PR214864.
A commit references this bug: Author: dim Date: Fri Oct 26 21:20:06 UTC 2018 New revision: 483054 URL: https://svnweb.freebsd.org/changeset/ports/483054 Log: Add all patches from base llvm/clang/lld/lldb 6.0 to devel/llvm60 This adds all the patches that were applied in the past to head, under contrib/llvm. After these, there only minimal diffs left between the port sources and the base sources. Most of these remaining diffs are due to #ifdef shortcuts in the base sources, because we don't compile certain features in. Other diffs are because the port has applied a few changes that we don't have in base. While here, use Makefile.LICENSE from the devel/llvm-devel port. Approved by: brooks (maintainer) Reviewed by: brooks PR: 212343, 225128, 225471, 226388, 226658, 226872, 229050, 230444, 230604, 231355 MFH: 2018Q4 Differential Revision: https://reviews.freebsd.org/D17702 Changes: head/devel/llvm60/Makefile head/devel/llvm60/files/clang/patch-head-r331066.diff head/devel/llvm60/files/clang/patch-head-r336227.diff head/devel/llvm60/files/clang/patch-head-r338697.diff head/devel/llvm60/files/clang/patch-head-r339019.diff head/devel/llvm60/files/lld/ head/devel/llvm60/files/lld/patch-head-r331731.diff head/devel/llvm60/files/lld/patch-head-r333401.diff head/devel/llvm60/files/lld/patch-head-r336664.diff head/devel/llvm60/files/lld/patch-head-r336972.diff head/devel/llvm60/files/lld/patch-head-r337282.diff head/devel/llvm60/files/lld/patch-head-r338251.diff head/devel/llvm60/files/lld/patch-head-r338682.diff head/devel/llvm60/files/lld/patch-head-r339013.diff head/devel/llvm60/files/lld/patch-head-r339304.diff head/devel/llvm60/files/lldb/ head/devel/llvm60/files/lldb/patch-head-r332849.diff head/devel/llvm60/files/lldb/patch-head-r332965.diff head/devel/llvm60/files/patch-head-r308867.diff head/devel/llvm60/files/patch-head-r330686.diff head/devel/llvm60/files/patch-head-r331065.diff head/devel/llvm60/files/patch-head-r331366.diff head/devel/llvm60/files/patch-head-r336969.diff head/devel/llvm60/files/patch-head-r336970.diff head/devel/llvm60/files/patch-head-r337615.diff head/devel/llvm60/files/patch-head-r338689.diff
A commit references this bug: Author: dim Date: Wed Oct 31 18:49:07 UTC 2018 New revision: 483602 URL: https://svnweb.freebsd.org/changeset/ports/483602 Log: MFH: r481120 Update to a new snapshot. Update LICENSE data per mailing list feedback and move to a seperate Makefile.LICENSE for use by other llvm ports. MFH: r483054 Add all patches from base llvm/clang/lld/lldb 6.0 to devel/llvm60 This adds all the patches that were applied in the past to head, under contrib/llvm. After these, there only minimal diffs left between the port sources and the base sources. Most of these remaining diffs are due to #ifdef shortcuts in the base sources, because we don't compile certain features in. Other diffs are because the port has applied a few changes that we don't have in base. While here, use Makefile.LICENSE from the devel/llvm-devel port. Approved by: portmgr (miwi) Reviewed by: brooks PR: 212343, 225128, 225471, 226388, 226658, 226872, 229050, 230444, 230604, 231355 Differential Revision: https://reviews.freebsd.org/D17702 Changes: _U branches/2018Q4/ branches/2018Q4/devel/llvm-devel/Makefile branches/2018Q4/devel/llvm-devel/Makefile.LICENSE branches/2018Q4/devel/llvm-devel/Makefile.snapshot branches/2018Q4/devel/llvm-devel/distinfo branches/2018Q4/devel/llvm-devel/files/lldb-patch-tools_lldb_source_Plugins_Process_FreeBSD_ProcessFreeBSD.cpp branches/2018Q4/devel/llvm-devel/pkg-plist branches/2018Q4/devel/llvm60/Makefile branches/2018Q4/devel/llvm60/files/clang/patch-head-r331066.diff branches/2018Q4/devel/llvm60/files/clang/patch-head-r336227.diff branches/2018Q4/devel/llvm60/files/clang/patch-head-r338697.diff branches/2018Q4/devel/llvm60/files/clang/patch-head-r339019.diff branches/2018Q4/devel/llvm60/files/lld/ branches/2018Q4/devel/llvm60/files/lldb/ branches/2018Q4/devel/llvm60/files/patch-head-r308867.diff branches/2018Q4/devel/llvm60/files/patch-head-r330686.diff branches/2018Q4/devel/llvm60/files/patch-head-r331065.diff branches/2018Q4/devel/llvm60/files/patch-head-r331366.diff branches/2018Q4/devel/llvm60/files/patch-head-r336969.diff branches/2018Q4/devel/llvm60/files/patch-head-r336970.diff branches/2018Q4/devel/llvm60/files/patch-head-r337615.diff branches/2018Q4/devel/llvm60/files/patch-head-r338689.diff