lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Message-ID: <Yh+dMJsH+ZMPfqwD@thelio-3990X> Date: Wed, 2 Mar 2022 09:37:04 -0700 From: Nathan Chancellor <nathan@...nel.org> To: Nick Desaulniers <ndesaulniers@...gle.com> Cc: Peter Zijlstra <peterz@...radead.org>, x86@...nel.org, joao@...rdrivepizza.com, hjl.tools@...il.com, jpoimboe@...hat.com, andrew.cooper3@...rix.com, linux-kernel@...r.kernel.org, keescook@...omium.org, samitolvanen@...gle.com, mark.rutland@....com, alyssa.milburn@...el.com, mbenes@...e.cz, rostedt@...dmis.org, mhiramat@...nel.org, alexei.starovoitov@...il.com, Masahiro Yamada <masahiroy@...nel.org>, Linux Kbuild mailing list <linux-kbuild@...r.kernel.org>, llvm@...ts.linux.dev Subject: Re: [PATCH v2 01/39] kbuild: Fix clang build On Tue, Mar 01, 2022 at 01:16:04PM -0800, Nick Desaulniers wrote: > On Thu, Feb 24, 2022 at 7:17 AM Peter Zijlstra <peterz@...radead.org> wrote: > > > > Debian (and derived) distros ship their compilers as -$ver suffixed > > binaries. For gcc it is sufficent to use: > > > > $ make CC=gcc-12 > > > > However, clang builds (esp. clang-lto) need a whole array of tools to be > > exactly right, leading to unweildy stuff like: > > > > $ make CC=clang-13 LD=ld.lld-13 AR=llvm-ar-13 NM=llvm-nm-13 OBJCOPY=llvm-objcopy-13 OBJDUMP=llvm-objdump-13 READELF=llvm-readelf-13 STRIP=llvm-strip-13 LLVM=1 > > > > which is, quite franktly, totally insane and unusable. Instead make > > the CC variable DTRT, enabling one such as myself to use: > > > > $ make CC=clang-13 > > > > This also lets one quickly test different clang versions. > > Additionally, also support path based LLVM suites like: > > > > $ make CC=/opt/llvm/bin/clang > > > > This changes the default to LLVM=1 when CC is clang, mixing toolchains > > No, nack, we definitely do not want CC=clang to set LLVM=1. Those are > distinctly two different things for testing JUST the compiler > (CC=clang) vs the whole toolchain suite (LLVM=1). I do not wish to > change the semantics of those, and only for LLVM. I agree with this. CC is only changing the compiler, not any of the other build utilities. CC=gcc-12 works for GCC because you are only using a different compiler, not an entirely new toolchain (as binutils will be the same as just CC=gcc). > LLVM=1 means test clang, lld, llvm-objcopy, etc.. > CC=clang means test clang, bfd, GNU objcopy, etc.. > https://docs.kernel.org/kbuild/llvm.html#llvm-utilities > > I don't wish to see the behavior of CC=clang change based on LLVM=0 being set. > > > is still possible by explicitly adding LLVM=0. > > Thanks for testing with LLVM, and even multiple versions of LLVM. > > I'm still sympathetic, but only up to a point. A change like this MUST > CC the kbuild AND LLVM maintainers AND respective lists though. It > also has little to do with the rest of the series. > > As per our previous discussion > https://lore.kernel.org/linux-kbuild/CAKwvOd=x9E=7WcCiieso-CDiiU-wMFcXL4W3V5j8dq7BL5QT+w@mail.gmail.com/ > I'm still of the opionion that this should be solved by modifications > (permanent or one off) to one's $PATH. However, I think we could still address Peter's complaint of "there should be an easier way for me to use the tools that are already in my PATH" with his first iteration of this patch [1], which I feel is totally reasonable: $ make LLVM=-14 It is still easy to use (in fact, it is shorter than 'CC=clang-14') and it does not change anything else about how we build with LLVM. We would just have to add something along the lines of "If your LLVM tools have a suffix like Debian's (clang-14, ld.lld-14, etc.), use LLVM=<suffix>. $ make LLVM=-14" to Documentation/kbuild/llvm.rst. I might change the patch not to be so clever though: ifneq ($(LLVM),) ifneq ($(LLVM),1) LLVM_SFX := $(LLVM) endif endif [1]: https://lore.kernel.org/r/YXqpFHeY26sEbort@hirez.programming.kicks-ass.net/ Cheers, Nathan
Powered by blists - more mailing lists