linux-kernel - Re: [PATCH] selftests: propagate CC to selftest submakes

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:   Thu, 10 Dec 2020 16:10:04 -0800
From:   Andrew Delgadillo <adelg@...gle.com>
To:     Nick Desaulniers <ndesaulniers@...gle.com>
Cc:     Shuah Khan <shuah@...nel.org>,
        Nathan Chancellor <natechancellor@...il.com>,
        "open list:KERNEL SELFTEST FRAMEWORK" 
        <linux-kselftest@...r.kernel.org>,
        LKML <linux-kernel@...r.kernel.org>,
        clang-built-linux <clang-built-linux@...glegroups.com>
Subject: Re: [PATCH] selftests: propagate CC to selftest submakes

On Thu, Dec 10, 2020 at 3:08 PM Nick Desaulniers
<ndesaulniers@...gle.com> wrote:
>
> On Thu, Dec 3, 2020 at 2:10 PM Andrew Delgadillo <adelg@...gle.com> wrote:
> >
> > lib.mk defaults to gcc when CC is not set. When building selftests
> > as part of a kernel compilation, MAKEFLAGS is cleared to allow implicit
> > build rules to be used. This has the side-effect of clearing the CC
> > variable, which will cause selftests to be built with gcc regardless of
> > if we are using gcc or clang. To remedy this, propagate the CC variable
> > when clearing makeflags to ensure the correct compiler is used.
> >
> > Signed-off-by: Andrew Delgadillo <adelg@...gle.com>
>
> Hi Andrew, thanks for the patch. Can you walk me through how to build
> the selftests?
>
> Documentation/dev-tools/kselftest.rst says:
> $ make -C tools/testing/selftests
>
> And if I do:
> $ make CC=clang defconfig
> $ make CC=clang -C tools/testing/selftests -j
>
> I observe a spew of errors.  If I apply your patch and rerun the
> above, I see what looks like the same spew of errors.  Am I "holding
> it wrong" or could the docs use a refresh?
>

Hi Nick, sure thing!

I also see a slew of errors when building with make -C
tools/testing/selftests. However, that is not the problem I am trying
to solve. I believe we are seeing errors building that way because it
is missing some make variables that are normally set up when building
from the kernel's top level makefile.

>From https://www.kernel.org/doc/html/latest/dev-tools/kselftest.html:
    To build and run tests with a single command, use:
        $ make kselftest

To illustrate what I am to fix, one can follow these steps:

Without patch:
$ cd kernel_root
$ make mrproper # Start fresh
$ make defconfig
$ make kselftest V=1 |& tee out1

At this point inspecting out1 will show that gcc is being used as the compiler.
Let's try to set it to clang.

$ make mrproper
$ make defconfig
$ make kselftest V=1 CC=clang |& tee out2

Inspecting out2 shows that clang is not used, but rather gcc. You will
get a similar result if you substitute CC=clang for LLVM=1.
We can verify that the CC variable is not properly propagated to the
submakes with the following addition to
tools/testing/selftests/android/Makefile's all recipe (this is the
first submake run):
...
all:
        echo "My CC compiler is $(CC)" && false
...

Following the above steps again will echo "My CC compiler is gcc" both
times, despite setting CC=clang in the second run. After applying my
patch, the CC variable will be properly propagated. The reason it was
not propagated properly in the first place is that we clear MAKEFLAGS
if implicit build rules are disabled (top level Makefile disables
them, but selftests need), which has the side effect of unsetting the
CC variable. Selftest's lib.mk defaults to gcc when CC is not set,
which is why we see CC=gcc even when we set CC=clang on the
commandline.

While this is not a problem if building with make -C
tools/testing/selftests/Makefile, it does present a problem for those
who build with the top level makefile like "make kselftest" or "make
vmlinux kselftest". One reason for doing it the second way is that
using the top level Makefile allows one to use flags like "LLVM=1".

> > ---
> >  tools/testing/selftests/Makefile | 6 ++++--
> >  1 file changed, 4 insertions(+), 2 deletions(-)
> >
> > diff --git a/tools/testing/selftests/Makefile b/tools/testing/selftests/Makefile
> > index d9c283503159..a4dd6d7e8276 100644
> > --- a/tools/testing/selftests/Makefile
> > +++ b/tools/testing/selftests/Makefile
> > @@ -90,10 +90,12 @@ FORCE_TARGETS ?=
> >
> >  # Clear LDFLAGS and MAKEFLAGS when implicit rules are missing.  This provides
> >  # implicit rules to sub-test Makefiles which avoids build failures in test
> > -# Makefile that don't have explicit build rules.
> > +# Makefile that don't have explicit build rules. Since lib.mk defaults to
> > +# using gcc for compilation when the CC variable is not set, we propagate the
> > +# CC variable so if clang is being used, selftests will build with clang.
> >  ifeq (,$(LINK.c))
> >  override LDFLAGS =
> > -override MAKEFLAGS =
> > +override MAKEFLAGS = CC=$(CC)
> >  endif
> >
> >  # Append kselftest to KBUILD_OUTPUT and O to avoid cluttering
> > --
> > 2.29.2.576.ga3fc446d84-goog
> >
>
>
> --
> Thanks,
> ~Nick Desaulniers