On Mon, Jan 31 2022, Greg Steuck <gne...@openbsd.org> wrote: > Patrick Wildt <patr...@blueri.se> writes: > >> regarding the missing userpace support: Since a few clang updates ago >> we import more than just the builtins of compiler-rt. This means we >> should have at least some related code in our tree, even if it is not >> built/complete.
In base this seems to be gnu/llvm/compiler-rt and its subdirs. Something not present right now in the devel/llvm port. >> From the recent static analyzer mail thread it looks >> like people prefer to have such stuff in ports-clang, so, whatever. I only glanced at this thread but there is probably pushback against making clang even bigger and slower to build, which is a thing that I can understand. I'm not sure it would be a problem to build a few more llvm support libraries like ubsan. libclang_rt.profile.a comes to mind as an existing library that is built as part of the make build/release process. > This may or may not be analogous. How hard is it to build a base/ports > program with clang from ports? If it's a simple matter of > make CC=/usr/local/bin/cc CFLAGS=-fsanitize=undefined > then it makes little difference whether the base compiler includes > the libraries for UBSan reporting. > > jca@ WDYT, should I first target devel/llvm to have UBSan working or go > straight to /usr/src? Hard to tell without diving in further. :) My gut feeling is that in the end this should be provided by the base system, just like the rest of the compiler-rt / clang_rt.profile stuff*. And since we seem to already have the code in base but not in ports, I guess the answer is "base". Obviously in that case you have to replace the cmake setup with Makefiles. Those are broad hints, let me know if I can help further. -- jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE
