public inbox for llvm@lists.linux.dev
 help / color / mirror / Atom feed
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

  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