Tracking Issue for llvmPackages_15 changes

[rrbutani]

This issue tracks the work left over from #194634.

Fixes/missed patches for LLVM 15

• missing attrs: llvmPackages_15: add attributes #213497 (thanks @Et7f3!)
• should be applied to LLVM 15: lldb_14: fix broken python3 site-packages and lua5_3 #207863
• need to apply llvmPackages_{14, git}.clang: add nostdlibinc flag #193636 after all; see here
  • clang_15: add nostdlibinc flag #217825
• llvmPackages_15: Building with clang++ using libcxx/-stdlib=libc++ fails #214524 (llvmPackages_15.libcxx: specify LIBCXX_CXX_ABI_{LIBRARY_PATH,INCLUDE_PATHS} for all cxxabis #216273)
• fix the license change: Revert "llvmPackages_15: update licenses" #217906
• lld: build with 2M stack size on musl #218657
• apply hardening flags: add FORTIFY_SOURCE=3 support #212498: clang_15: mark hardeningUnsupportedFlags fortify3 #218676
• llvm_15: reenable libclang_rt.profile-....a build on musl #217042
• drop the compiler-rt sigtool codesigning patch: llvmPackages_15.compiler-rt: drop codesign patch #218800

In-flight

• llvmPackages_*.clangUseLLVM: add libunwind to lib search path (#201591) #220520
• llvmPackages_*.clang: bind linker on compiling clang #220595
• llvmPackages: add overrideable withLibunwind #207325
• llvmPackages_10: Make mkExtraBuildCommands overridable #196006

Unifying llvmPackages_git with llvmPackages_15

• llvmPackages_git: fix cross eval #211225
• llvmPackages_git.bintools: fix eval #217824
• compiler-rt fixes: llvmPackages_git.compiler-rt: fix build #217844
• use ninja: llvmPackages_git: switch to using ninja #218620
• lld: build with 2M stack size on musl #218657
• clang: drop the C++ std version -DCMAKE_CXX_FLAG #218671
• llvmPackages.compiler-rt: enable libclang_rt.profile-....a build #218799
• enable polly: llvm_14,llvmPackages_git.llvm: enable polly by default #218806
• llvm: add in a missing check dep #218865
• libcxx stdenv change: llvmPackages_git.libcxx: use clang from git instead of the stdenv's compiler #220527
• llvmPackages*.clang_manpages: drop the sphinx find_package patch #218640
• enable llvm tests on darwin: llvmPackages_git.llvm: run the tests on macOS #222220
• disable iOS simulator targets in compiler-rt: llvmPackages_git.compiler-rt: disable iPhone simulator #223256
• misc libcxx changes: llvmPackages_git.libcxx: LLVM15 changes and libcxxrt on FreeBSD #223255
• llvmPackages_git: apply #190936 (fix pkgsStatic LLVM build) #222901
• apply llvm: disable libpfm on all non-Linux platforms #205355: llvmPackages_git: apply #205355 (disable libpfm on non-Linux) #222902
• openmp apply openmp: fix cross compile #197674: llvmPackages_git.openmp: apply #197674 (fix cross compile) #222903
• apply lldb_14: fix broken python3 site-packages and lua5_3 #207863
• bump to LLVM 15: llvmPackages_git: bump to LLVM 15 #222894

Tracking the current state of llvmPackages_git (i.e. all the PRs listed above applied) here: rrbutani/tracking/llvm-git-parity

LLVM Package Set Updates

• bump llvmPackages_latest (llvmPackages_latest: 14 -> 15 #213202)
• backport llvmPackages_15 ([Backport release-22.11] llvmPackages_15: init at 15.0.7 #213092, [Backport release-22.11] lib.teams.llvm: create #213093)

---

Tests and additional coverage:

• libcxx tests
  • x86_64-darwin (@Et7f3)
  • other platforms
• cc-wrapper tests for sanitizers
• extra cc-wrapper tests for PGO, perhaps?
• stdenv tests on other platforms
• fix these: 1, 2, 3 (either remove or decide that these should gate channel advancement)

Issues/bugs:

• fix use as a cross-compiler targeting FreeBSD (libcxx currently fails to build)
• fix pkgsStatic.llvmPackages_15
• follow up on the armv7l build (didn't finish building before llvmPackages_15: init at 15.0.7 #194634 was merged)
• the three failing x86_64-darwin LLVM tests
  • one: roundevenf isn't present on x86_64-darwin; unclear if this is expected or not
  • two: sw_vers on aarch64-darwin links against frameworks (CoreFoundation) outside the sandbox
  • three: crash in a dsymutil test

Future Work/Wishlist

(not tracked by this issue; will point to issues here as we begin working on these things)

• common LLVM function across the package sets
• LLVM 16
• updating llvmPackages_git to tip-of-tree
• bumping llvmPackages to newer LLVM
• MLIR
• BOLT
• auto updater
• splitting useLLVM
• expanding test coverage (i.e. enabling doCheck on more packages/platforms)
• adding regression tests for the stdenv(s)
• building LTO/PGO/bolt optimized binaries in the llvmPackages sets
• reducing closure size of LLVM by splitting out the .a files in lib outputs? (but in a way that doesn't break users of LLVM static libs..)

[Et7f3]

Cool the PR is merged is their a Darwin task you are not working on ?

[rrbutani]

@Et7f3 I think, for now, I'm planning to focus on doing what I can to help bump llvmPackages_latest and then to update llvmPackages_git.

I'm still gathering my notes to update the OP with but off the top of my head, for darwin:

• I didn't really get to the bottom of the three test failures, detailed in this commit
  • one, two, three
  • for the first one it probably makes sense to dig deeper into if/why the JIT test that links against roundevenf succeeds on aarch64-darwin (is the test actually running on aarch64-darwin? if so, where does that symbol come from, libSystem? is this an artifact of us seemingly using system frameworks – the second issue – on aarch64-darwin? etc)
  • the second one is pretty spooky (and the commit message linked above has more details about how to reproduce it) and probably involves digging into the aarch64-darwin stdenv and the build steps for DarwinTools to figure out why the system framework is getting linked
  • I haven't looked into the third one at all but verifying that that test case fails outside the sandbox too is probably a good place to start
• Actually using the llvmPackages_15 stdenv (as part of this test script – note that aarch64-darwin and x86_64-darwin are commented out there in systems) leads to cycle errors on darwin
  • I don't have a good understanding of why; it seems like our stdenv gets used for some bootstrapping things, creating a cycle but it's not apparent to me why that doesn't affect the default (LLVM based) darwin stdenv
• I wanted to maybe try enabling the tests for other packages in the set (libcxx and clang to start with)
  • this isn't strictly a darwin task but I'm sure we'll end up needing to spend time figuring out darwin/linux/etc specific fails as part of this 😃

If any of the above things sound interesting to you, let me know; I can update the OP accordingly and try to provide some more context.

None of the above are high priority or anything though; if there's something else you're interested in working on (i.e. getting cross-compiling LLVM to work in more configurations, experimenting with ways to share package definitions between the llvmPackages_* sets, etc) definitely feel free to pursue that instead!

[Et7f3]

In the other PR this technique was used for newer requirements #209536 (comment) it use gcc on linux and not clang which might not be the default. This patch avoid mixing compiler, What do you think ?

I think I will try to enable test for libcxx on x86_64-darwin. I thought on enabling the test on all platforms and disabling those failing like

nixpkgs/pkgs/development/compilers/llvm/15/llvm/default.nix

Lines 239 to 243 in 84eed3e

	# !!! Note: these tests are removed in LLVM 16.
	#
	# See here for context: https://github.com/NixOS/nixpkgs/pull/194634#discussion_r999790443
	rm test/CodeGen/RISCV/rv32zbp.ll
	rm test/CodeGen/RISCV/rv64zbp.ll

So other works doesn't add regression and we can still keep progress.

[Et7f3]

Also linking a PR linked to these #213497

[rrbutani]

@Et7f3 Apologies for the late response.

In the other PR this technique was used for newer requirements #209536 (comment) it use gcc on linux and not clang which might not be the default. This patch avoid mixing compiler, What do you think ?

I believe it's okay for us to mix and match compilers and that it's mixing C++ stdlib/libc impls that's cause for concern. For example, AIUI, llvmPackages.stdenv exists and defaults to the platform's C++ stdlib instead of always using libc++ specifically so that some packages -- like chromium -- can use clang but can still link against other libraries compiled against libstdc++ (default on linux targets).

In the case of libc++/libc++-abi, we aren't linking against a C++ stdlib impl anyways (and the stdenv we use to build these packages is careful to use the platform's libc) so I think this isn't a concern for us (those with more experience in this area should definitely feel free to weigh in or clarify).

Given that, I think using the clang that's built alongside libcxx is preferable; it mirrors how libc++ is built in upstream LLVM and it lets us avoid having to maintain logic to select a new-enough gcc version, per-platform.

I think I will try to enable test for libcxx on x86_64-darwin.

That sounds great! I'll add an item for this in the OP; let me know if you open any issues or PRs and I can add them too.

[Artturin]

should be applied to LLVM 15: #207863

almost fix in #230387 , will have to be actually fixed in a staging PR

[pca006132]

I managed to get Bolt built in #176536 (comment), not yet tested (will do in a few days). A lot of patching has to be done, should I open a PR or try to get something upstreamed first?