linux-kernel - Re: [PATCH] kbuild: Support clang-$ver builds

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

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAKwvOd=x9E=7WcCiieso-CDiiU-wMFcXL4W3V5j8dq7BL5QT+w@mail.gmail.com>
Date:   Thu, 28 Oct 2021 16:27:55 -0700
From:   Nick Desaulniers <ndesaulniers@...gle.com>
To:     Peter Zijlstra <peterz@...radead.org>
Cc:     Nathan Chancellor <nathan@...nel.org>,
        Masahiro Yamada <masahiroy@...nel.org>,
        Michal Marek <michal.lkml@...kovi.net>,
        X86 ML <x86@...nel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Linux Kbuild mailing list <linux-kbuild@...r.kernel.org>,
        llvm@...ts.linux.dev
Subject: Re: [PATCH] kbuild: Support clang-$ver builds

On Thu, Oct 28, 2021 at 1:49 PM Peter Zijlstra <peterz@...radead.org> wrote:
>
> On Thu, Oct 28, 2021 at 10:44:06AM -0700, Nathan Chancellor wrote:
>
> > I like the first iteration of this idea most, as CC=clang does not
> > currently imply using all LLVM tools. There are some architectures that
> > work with CC=clang but not LLVM=1 so I am not sure we want that meaning
> > to change.
>
> Could such architecture set a CONFIG symbol to indicate they're
> handicapped and have that make the Makefile not use the full LLVM suite?

At this point, it's just powerpc and s390 where the assembler in llvm
needs more work. Every other arch we can compile we generally can
generally link. (modulo some long tail configs).

> > 2. Update the documentation to describe using the
> >
> >    $ PATH=/usr/lib/llvm-#/bin:$PATH make LLVM=1 ...
> >
> >    trick. This has been the preferred method for using different
> >    versions of LLVM but it has never been documented anywhere. This
> >    would allow us to keep the current build infrastructure while giving
> >    people clear instructions for how to handle different versions of
> >    clang. As Peter has noted, this would require people who are not
> >    familiar with building with LLVM to be constantly looking at the
> >    documentation to remember the command to invoke, whereas with
> >    LLVM=-#, it is easy to remember.
>
> Right, this is no more than a crude hack and is super unfriendly. It
> should never have been accepted.

Lots of tools modify PATH in your `.bashrc` or `.zshrc` etc.  I don't
see how that's any different, other than one off commands in which you
actually intend to use a specific version.

> So how about we do the below instead? Then the normal way of things will
> be:
>
>  $ make CC=clang-12
>
> and it will all *just*work*. The incomplete LLVM archs can revert back
> to the old hybrid (clang+binutils) way of things by doing:
>
>  $ make CC=clang LLVM=0
>
> Which explicitly states, use clang but don't use the full llvm suite. Or
> they can do that CONFIG_LLVM_BROKEN (or whatever) to have them default
> to LLVM=0
>
> ifdef CONFIG_LLVM_BROKEN
> LLVM ?= 0
> endif
>
> in front of the CC magic in the below patch should take care of that.

I don't think setting CC should affect LD and friends (if you were
suggesting that CC=clang-12 replace LLVM=1).  Like Nathan, I'm
sympathetic and think that your first patch is probably closer to what
I'd accept, but it needs to handle non-suffixed versions (looks like
it should) and add this info to Documentations/kbuild/llvm.rst.
-- 
Thanks,
~Nick Desaulniers