Date: Sun, 27 Apr 2025 15:04:11 +0000 From: Shawn Webb <shawn.webb@hardenedbsd.org> To: Dimitry Andric <dim@freebsd.org> Cc: FreeBSD CURRENT <freebsd-current@freebsd.org> Subject: Re: HEADS UP: libllvm, libclang, and liblldb converted into shared libraries Message-ID: <qbula3o6nf2f5xkpb4vu6p7d25of6z3hvtqfhr2x2rfr3flesh@6fzyxd7qnl3a> In-Reply-To: <B44B37E9-16C8-46B2-95CA-2A9072174FFF@FreeBSD.org>
index | next in thread | previous in thread | raw e-mail
[-- Attachment #1 --] On Sat, Apr 26, 2025 at 06:06:54PM +0200, Dimitry Andric wrote: > Hi, > > In https://cgit.freebsd.org/src/commit/?id=2e47f35be5dc I committed a > change to convert libllvm, libclang, and liblldb into private shared > libraries. This means that tools like clang, lld, lldb, and more are now > quite a bit smaller, as all the common functionality is located in those > shared libraries. > > Note that these shared libraries are not the same as upstream's, and are > _not_ ABI compatible, which is why they are installed as private shared > libraries. If you need ABI compatibility and/or the llvm-config tools, > please use one of the devel/llvm ports. > > This affects the following binaries in the base system (some of them > only exist if they're enabled through various WITH_XXX options): > > - addr2line > - ar > - bugpoint > - c++ > - c++filt > - cc > - clang > - clang++ > - clang-cpp > - clang-format > - cpp > - gcov > - ld.lld > - llc > - lldb > - lldb-server > - lli > - llvm-addr2line > - llvm-ar > - llvm-as > - llvm-bcanalyzer > - llvm-cov > - llvm-cxxdump > - llvm-cxxfilt > - llvm-diff > - llvm-dis > - llvm-dwarfdump > - llvm-dwarfutil > - llvm-dwp > - llvm-extract > - llvm-link > - llvm-lto > - llvm-lto2 > - llvm-mc > - llvm-mca > - llvm-modextract > - llvm-nm > - llvm-objcopy > - llvm-objdump > - llvm-pdbutil > - llvm-profdata > - llvm-ranlib > - llvm-readelf > - llvm-readobj > - llvm-rtdyld > - llvm-size > - llvm-strings > - llvm-strip > - llvm-symbolizer > - llvm-xray > - nm > - objcopy > - objdump > - opt > - ranlib > - readelf > - size > - strings > - strip > > In addition, all these executables are now position independent (PIE). > > Please let me know if you encounter any problems resulting due to this > change, as I intend to MFC it. For example, I tried covering all > incremental build scenarios, but I may have missed some corner case. Hey Dimitry, I suspect this may be a problem specific to HardenedBSD, but it looks like cc occasionally crashes. It hits an assert at /usr/src/contrib/llvm-project/clang/lib/Driver/Driver.cpp:2702. I can reproduce this by running `env SHELL=/bin/sh make buildenv` at the top of /usr/src. Though, it doesn't reproduce 100%, but perhaps around 60%. ==== BEGIN BACKTRACE ==== hbsd-current-01[shawn]:/usr/src $ lldb /usr/bin/cc -c /usr/obj/usr/src/amd64.amd64/cc.core [8:53:37] (lldb) target create "/usr/bin/cc" --core "/usr/obj/usr/src/amd64.amd64/cc.core" Core file '/usr/obj/usr/src/amd64.amd64/cc.core' (x86_64) was loaded. (lldb) bt * thread #1, name = 'cc', stop reason = signal SIGABRT * frame #0: 0x000004c0ae52854a libsys.so.7`__sys_thr_kill at thr_kill.S:4 frame #1: 0x000004c0a9751bdc libc.so.7`__raise(s=6) at raise.c:48:10 frame #2: 0x000004c0a98177f4 libc.so.7`abort at abort.c:73:8 frame #3: 0x000004c0a97326c1 libc.so.7`__assert(func=<unavailable>, file=<unavailable>, line=<unavailable>, failedexpr=<unavailable>) at assert.c:47:2 frame #4: 0x000004c0ac698e70 libprivateclang.so.19`::BuildInputs() at Driver.cpp:2702:13 frame #5: 0x000004c0ac69e536 libprivateclang.so.19`::generateCompilationDiagnostics() at Driver.cpp:1744:3 frame #6: 0x0000013704d7961f cc`::maybeGenerateCompilationDiagnostics() at Driver.h:577:5 frame #7: 0x0000013704d781f8 cc`::clang_main() at driver.cpp:426:15 frame #8: 0x0000013704d763aa cc`main at clang-driver.cpp:17:10 frame #9: 0x000004c0a9722d70 libc.so.7`__libc_start1(argc=3, argv=0x000079004f9a3608, env=0x000079004f9a3628, cleanup=<unavailable>, mainX=(cc`main at clang-driver.cpp:15)) at libc_start1.c:172:7 frame #10: 0x0000013704d674f1 cc`_start at crt1_s.S:80 ==== END BACKTRACE ==== If you have any initial thoughts, please let me know. I'm not well-versed in llvm's internals. I'm also unsure why `make buildenv` would cause `cc` to run, so that's another gap of knowledge I need to fill. Thanks, -- Shawn Webb Cofounder / Security Engineer HardenedBSD Signal Username: shawn_webb.74 Tor-ified Signal: +1 303-901-1600 / shawn_webb_opsec.50 https://git.hardenedbsd.org/hardenedbsd/pubkeys/-/raw/master/Shawn_Webb/03A4CBEBB82EA5A67D9F3853FF2E67A277F8E1FA.pub.asc [-- Attachment #2 --] -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEEA6TL67gupaZ9nzhT/y5nonf44foFAmgOR1wACgkQ/y5nonf4 4fpfww/7Bamc/A+CtSLfKrIKugFaL9iGRvZ2BZPOeeiMLQvuurpMJEAyqhfbOEAP 8NDGJzEadLLCSZXQ99+UVOH5/6zsnfE+I9dDkAVR4T72Ono1S+gDdM0AczHvMhDF uMockk9XSCc+28Uzx4au/ZwrtD/attdM/Ze/XX8uDAl+U+y+X6AGN82CgSeCyhUV cLzxg+RXV3uypfKUedfdHI/k7mUFbG/gnUQg5Di9yi7dWuKbBWhh/dYarMzBs/4n sj9wDxtf6+qJT+j1ZGQiwY52427WAXeZP2P9xv3CDwZRvfg7/smmEwHQUxaYR7Sw f24BXGHi4xPPfwbRtOYE2r/Ihxd2v34xNgyQ3Ub9rhMOrHvcvaXVprOQYmtGEYVp Bgla3w6ggitVZoqoivI+/F0aiSO6Ic0Tz6AZnRC9v05FstvxURHlvzDTgYTuahrq PJt8kHFlHYcS276AjjiNhQJUv/fpabYEFcZ4sGkn5jg2REpDSFAuJeo5wmbC9ebX UFPYZEynuatKw2OZXtYINEKsOm2VmMNQSbkT83h8cI47SmTjKo4cwcDFhdiQ3+EP RFTexPLpZDA+veNyYzjy+jQ5AyuxXRnk6DfGSwSQaDcuCNA2wpIcPhUDFpVJTYyk db66Th3ElvS2JRhGIBqsQ8g92RzWXW3msvOvil5KMNWKAiCBhM0= =5iRP -----END PGP SIGNATURE-----help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?qbula3o6nf2f5xkpb4vu6p7d25of6z3hvtqfhr2x2rfr3flesh>