linux-kernel - Re: [PATCH] kbuild: support 'LLVM' to switch the default tools to Clang/LLVM

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]

Date:   Mon, 6 Apr 2020 10:33:40 +0900
From:   Masahiro Yamada <masahiroy@...nel.org>
To:     Fangrui Song <maskray@...gle.com>
Cc:     Nick Desaulniers <ndesaulniers@...gle.com>,
        Linux Kbuild mailing list <linux-kbuild@...r.kernel.org>,
        Nathan Chancellor <natechancellor@...il.com>,
        clang-built-linux <clang-built-linux@...glegroups.com>,
        Jonathan Corbet <corbet@....net>,
        Michal Marek <michal.lkml@...kovi.net>,
        Linux Doc Mailing List <linux-doc@...r.kernel.org>,
        LKML <linux-kernel@...r.kernel.org>,
        Matthias Männich <maennich@...gle.com>,
        Sandeep Patil <sspatil@...gle.com>
Subject: Re: [PATCH] kbuild: support 'LLVM' to switch the default tools to Clang/LLVM

On Mon, Apr 6, 2020 at 8:55 AM 'Fangrui Song' via Clang Built Linux
<clang-built-linux@...glegroups.com> wrote:
>
> On 2020-04-06, Masahiro Yamada wrote:
> >On Sat, Apr 4, 2020 at 3:24 AM Nick Desaulniers <ndesaulniers@...gle.com> wrote:
> >>
> >> On Thu, Apr 2, 2020 at 10:17 PM Masahiro Yamada <masahiroy@...nel.org> wrote:
> >> >
> >> > As Documentation/kbuild/llvm.rst implies, building the kernel with a
> >> > full set of LLVM tools gets very verbose and unwieldy.
> >> >
> >> > Provide a single switch 'LLVM' to use Clang and LLVM tools instead of
> >> > GCC and Binutils. You can pass LLVM=1 from the command line or as an
> >> > environment variable. Then, Kbuild will use LLVM toolchains in your
> >> > PATH environment.
> >> >
> >> > Please note LLVM=1 does not turn on the LLVM integrated assembler.
> >> > You need to explicitly pass AS=clang to use it. When the upstream
> >> > kernel is ready for the integrated assembler, I think we can make
> >> > it default.
> >>
> >> Having this behavior change over time may be surprising.  I'd rather
> >> that if you want to not use the integrated assembler, you explicitly
> >> negate it, or just don't use the LLVM=1 syntax, ie. `make CC=clang
> >> LD=ld.lld ...`.
> >>
> >> We could modify how `-no-integrated-as` is chosen when LLVM=1.
> >>
> >> make LLVM=1 LLVMIA=0 ... # add `-no-integrated-as`
> >> # what the flag is doesn't really matter to me, something shorter might be nice.
> >> make LLVM=1 # use all LLVM tools
> >>
> >> Since we got rid of $(AS), it would be appropriate to remove/change it
> >> there, since no one really relies on AS=clang right now. (We do have 1
> >> of our 60+ CI targets using it, but we can also change that trivially.
> >> So I think we have a lot of freedom to change how `-no-integrated-as`
> >> is set.
> >>
> >> This could even be independent of this patch.
> >
> >
> >I also thought a boolean flag is preferred.
> >
> >AS=clang will not live long anyway, and
> >I hesitated to break the compatibility
> >for the short-term workaround.
> >
> >But, if this is not a big deal, I can
> >replace AS=clang with LLVMIA=1.
>
> My mere complaint is that it may be difficult to infer the intention (integrated
> assembler) from the abbreviation "IA" in "LLVMIA" :/
>
> Something with "AS" in the name may be easier for a user to understand,
> e.g. CLANG_AS or LLVM_AS.




I see 'llvm-as' in my PATH,
but it is a different kind of tool, right?
(converter from LLVM assembler *.ll to LLVM bit code *.bc)

So, I thought "LLVM_AS" might be confusing.



-- 
Best Regards
Masahiro Yamada