Bug 225128 - [exp-run] with LLD_BOOTSTRAP on i386
Summary: [exp-run] with LLD_BOOTSTRAP on i386
Status: Closed FIXED
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Ports Framework (show other bugs)
Version: Latest
Hardware: Any Any
: --- Affects Only Me
Assignee: Ed Maste
URL:
Keywords:
Depends on: 225230 225351 225353 225406 228753
Blocks: 229050
  Show dependency treegraph
 
Reported: 2018-01-13 04:05 UTC by Ed Maste
Modified: 2018-10-31 18:49 UTC (History)
5 users (show)

See Also:


Attachments
Revert r327910, reapply WITH_LLD_BOOTSTRAP for i386 (1.75 KB, patch)
2018-01-13 04:05 UTC, Ed Maste
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Ed Maste freebsd_committer 2018-01-13 04:05:16 UTC
Created attachment 189675 [details]
Revert r327910, reapply WITH_LLD_BOOTSTRAP for i386

Regressions reported in i386 ports with WITH_LLD_BOOTSTRAP, reverted in r327910.
Comment 2 Kirill Ponomarev freebsd_committer 2018-01-13 10:51:34 UTC
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
Comment 4 Antoine Brodin freebsd_committer 2018-01-13 12:39:44 UTC
(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
Comment 5 Antoine Brodin freebsd_committer 2018-01-15 08:17:20 UTC
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
Comment 6 Ed Maste freebsd_committer 2018-01-15 14:27:20 UTC
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)
Comment 7 Antoine Brodin freebsd_committer 2018-01-20 11:51:55 UTC
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.
Comment 8 Ed Maste freebsd_committer 2018-01-20 15:41:50 UTC
(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.
Comment 9 Ed Maste freebsd_committer 2018-01-20 15:44:11 UTC
(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.
Comment 10 Ed Maste freebsd_committer 2018-01-20 16:05:30 UTC
(In reply to Ed Maste from comment #9)
Or, it may be a regression from lld 5 to lld 6.
Comment 11 Antoine Brodin freebsd_committer 2018-01-20 16:26:15 UTC
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.
Comment 12 Dimitry Andric freebsd_committer 2018-01-20 18:52:36 UTC
(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.
Comment 13 Ed Maste freebsd_committer 2018-01-20 22:43:41 UTC
Dimitry found the responsible lld change and submitted https://bugs.llvm.org/show_bug.cgi?id=36029
Comment 14 Jan Beich freebsd_committer 2018-01-21 20:04:09 UTC
Maybe LLD_BOOTSTRAP should be temporarily disabled for amd64. Workarounds for libgcc_s and libcxxrt issues shouldn't land in ports unlike LLD_UNSAFE.
Comment 15 Antoine Brodin freebsd_committer 2018-01-23 16:31:13 UTC
Could LLD_BOOTSTRAP be reverted on amd64 if there is no pending fix?
Comment 16 Ed Maste freebsd_committer 2018-01-23 16:33:17 UTC
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.
Comment 17 Ed Maste freebsd_committer 2018-01-23 17:55:50 UTC
The lld DT_NEEDED issue should be fixed as of r328286.
Comment 18 Antoine Brodin freebsd_committer 2018-01-23 20:55:08 UTC
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)
Comment 19 Ed Maste freebsd_committer 2018-01-23 22:20:44 UTC
> 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.
Comment 20 commit-hook freebsd_committer 2018-01-23 22:42:06 UTC
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
Comment 21 commit-hook freebsd_committer 2018-01-30 01:13:54 UTC
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
Comment 22 Ed Maste freebsd_committer 2018-01-30 01:21:46 UTC
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.
Comment 23 Antoine Brodin freebsd_committer 2018-02-04 10:15:13 UTC
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
Comment 24 Ed Maste freebsd_committer 2018-04-15 00:50:50 UTC
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)
Comment 25 Mark Johnston freebsd_committer 2018-05-28 17:38:21 UTC
(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.
Comment 26 Ed Maste freebsd_committer 2018-05-28 19:47:51 UTC
I'd like to request another exp-run of this change.
Comment 27 Ed Maste freebsd_committer 2018-05-31 14:14:03 UTC
Main PR 214864 also updated with patch to enable both LLD options (LLD_BOOTSTRAP and LLD_IS_LD) for i386.
Comment 28 Antoine Brodin freebsd_committer 2018-06-01 14:10:25 UTC
I have a problem,  it seems WITH_LLD_BOOTSTRAP implies LLD_IS_LD ...
Comment 29 Antoine Brodin freebsd_committer 2018-06-01 14:12:08 UTC
(In reply to Antoine Brodin from comment #28)
scratch this, i'm building for amd64 instead of i386
Comment 30 Antoine Brodin freebsd_committer 2018-06-01 19:48:21 UTC
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
Comment 31 Mark Johnston freebsd_committer 2018-06-04 19:38:43 UTC
(In reply to Antoine Brodin from comment #30)
What are you building when that occurs?
Comment 32 Antoine Brodin freebsd_committer 2018-06-04 20:07:07 UTC
(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
Comment 33 Mark Johnston freebsd_committer 2018-06-04 20:15:45 UTC
(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>
Comment 34 Mark Johnston freebsd_committer 2018-06-04 21:03:54 UTC
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
Comment 35 commit-hook freebsd_committer 2018-07-24 11:36:17 UTC
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
Comment 36 Ed Maste freebsd_committer 2018-07-24 14:18:44 UTC
I think the issues tracked in PR228574 and PR228753 should now be fixed, and we should be ready for another exp-run.
Comment 37 Antoine Brodin freebsd_committer 2018-07-24 21:36:40 UTC
ok, I will test once head is unbroken...
Comment 38 Ed Maste freebsd_committer 2018-07-24 23:11:18 UTC
https://ci.freebsd.org/tinderbox/ shows HEAD all green except riscv64; what is the issue?
Comment 39 Mark Johnston freebsd_committer 2018-07-25 00:20:59 UTC
(In reply to Ed Maste from comment #38)
Presumably https://lists.freebsd.org/pipermail/svn-src-all/2018-July/167754.html
Comment 40 Ed Maste freebsd_committer 2018-07-25 00:34:48 UTC
(In reply to Mark Johnston from comment #39)
Ah, indeed, now fixed by r336693.
Comment 41 commit-hook freebsd_committer 2018-07-30 00:09:28 UTC
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
Comment 42 Antoine Brodin freebsd_committer 2018-07-30 09:17:41 UTC
Exp-run looks fine.
Comment 43 commit-hook freebsd_committer 2018-07-30 12:38:56 UTC
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
Comment 44 Ed Maste freebsd_committer 2018-07-30 13:23:11 UTC
Thank you for the exp-run. exp-run for LLD_IS_LD on i386 is in PR214864.
Comment 45 commit-hook freebsd_committer 2018-10-26 21:20:41 UTC
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
Comment 46 commit-hook freebsd_committer 2018-10-31 18:49:35 UTC
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