From: Kees Cook <keescook@chromium.org>
To: Nathan Chancellor <nathan@kernel.org>
Cc: Nick Desaulniers <ndesaulniers@google.com>,
Peter Zijlstra <peterz@infradead.org>,
x86@kernel.org, joao@overdrivepizza.com, hjl.tools@gmail.com,
jpoimboe@redhat.com, andrew.cooper3@citrix.com,
linux-kernel@vger.kernel.org, samitolvanen@google.com,
mark.rutland@arm.com, alyssa.milburn@intel.com, mbenes@suse.cz,
rostedt@goodmis.org, mhiramat@kernel.org,
alexei.starovoitov@gmail.com,
Masahiro Yamada <masahiroy@kernel.org>,
Linux Kbuild mailing list <linux-kbuild@vger.kernel.org>,
llvm@lists.linux.dev
Subject: Re: [PATCH v2 01/39] kbuild: Fix clang build
Date: Wed, 2 Mar 2022 15:00:44 -0800 [thread overview]
Message-ID: <202203021459.55F4992@keescook> (raw)
In-Reply-To: <Yh/egU1LZudfrgVy@dev-arch.thelio-3990X>
On Wed, Mar 02, 2022 at 02:15:45PM -0700, Nathan Chancellor wrote:
> Sounds good, tentative patch attached, it passes all of my testing.
> There is an instance of $(LLVM) in tools/testing/selftests/lib.mk that I
> did not touch, as that will presumably have to go through the selftests
> tree. I can send a separate patch for that later.
I think it's fine to include that here, just to keep the logic together.
> Peter, is this approach okay with you? If so, would you like to be
> co-author or should I use a suggested-by tag?
>
> Cheers,
> Nathan
> From 83219caafbb7dbc2e41e3888ba5079d342aff633 Mon Sep 17 00:00:00 2001
> From: Nathan Chancellor <nathan@kernel.org>
> Date: Wed, 2 Mar 2022 13:28:14 -0700
> Subject: [PATCH] kbuild: Allow a suffix with $(LLVM)
>
> The LLVM variable allows a developer to quickly switch between the GNU
> and LLVM tools. However, it does not handle versioned binaries, such as
> the ones shipped by Debian, as LLVM=1 just defines the build variables
> with the unversioned binaries.
>
> There was some discussion during the review of the patch that introduces
> LLVM=1 around this, ultimately coming to the conclusion that developers
> can just add the folder that contains the unversioned binaries to their
> PATH, as Debian's versioned suffixed binaries are really just symlinks
> to the unversioned binaries in /usr/lib/llvm-#/bin:
>
> $ realpath /usr/bin/clang-14
> /usr/lib/llvm-14/bin/clang
>
> $ PATH=/usr/lib/llvm-14/bin:$PATH make ... LLVM=1
>
> However, it is simple enough to support this scheme directly in the
> Kbuild system by allowing the developer to specify the version suffix
> with LLVM=, which is shorter than the above suggestion:
>
> $ make ... LLVM=-14
>
> It does not change the meaning of LLVM=1 (which will continue to use
> unversioned binaries) and it does not add too much additional complexity
> to the existing $(LLVM) code, while allowing developers to quickly test
> their series with different versions of the whole LLVM suite of tools.
>
> Signed-off-by: Nathan Chancellor <nathan@kernel.org>
I like it!
Reviewed-by: Kees Cook <keescook@chromium.org>
--
Kees Cook
next prev parent reply other threads:[~2022-03-02 23:00 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20220224145138.952963315@infradead.org>
[not found] ` <20220224151322.307406918@infradead.org>
2022-02-25 0:35 ` [PATCH v2 05/39] x86: Base IBT bits Kees Cook
2022-02-25 0:46 ` Nathan Chancellor
2022-02-25 22:08 ` Nathan Chancellor
2022-02-26 0:29 ` Joao Moreira
2022-02-26 4:58 ` Kees Cook
2022-02-26 4:59 ` Fāng-ruì Sòng
2022-02-26 5:04 ` Kees Cook
2022-02-25 13:41 ` Peter Zijlstra
[not found] ` <20220224151322.072632223@infradead.org>
2022-02-25 0:11 ` [PATCH v2 01/39] kbuild: Fix clang build Kees Cook
2022-03-01 21:16 ` Nick Desaulniers
2022-03-02 0:47 ` Kees Cook
2022-03-02 0:53 ` Fangrui Song
2022-03-02 16:37 ` Nathan Chancellor
2022-03-02 18:40 ` Kees Cook
2022-03-02 19:18 ` Nick Desaulniers
2022-03-02 21:15 ` Nathan Chancellor
2022-03-02 22:07 ` Nick Desaulniers
2022-03-02 23:00 ` Kees Cook [this message]
2022-03-02 23:10 ` Peter Zijlstra
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=202203021459.55F4992@keescook \
--to=keescook@chromium.org \
--cc=alexei.starovoitov@gmail.com \
--cc=alyssa.milburn@intel.com \
--cc=andrew.cooper3@citrix.com \
--cc=hjl.tools@gmail.com \
--cc=joao@overdrivepizza.com \
--cc=jpoimboe@redhat.com \
--cc=linux-kbuild@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=llvm@lists.linux.dev \
--cc=mark.rutland@arm.com \
--cc=masahiroy@kernel.org \
--cc=mbenes@suse.cz \
--cc=mhiramat@kernel.org \
--cc=nathan@kernel.org \
--cc=ndesaulniers@google.com \
--cc=peterz@infradead.org \
--cc=rostedt@goodmis.org \
--cc=samitolvanen@google.com \
--cc=x86@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox