Re: MIPS + clang-11 + allnoconfig / tinyconfig builds failed

[Nick Desaulniers]

On Thu, Dec 10, 2020 at 9:18 AM Naresh Kamboju
<naresh.kamboju@xxxxxxxxxx> wrote:
>
> Recently we have setup clang build and found that,
> MIPS + clang-11 + allnoconfig  build failed
> MIPS + clang-11 + tinyconfig  build failed
>
> MIPS + clang-10 + allnoconfig  build failed
> MIPS + clang-10 + tinyconfig  build failed
>
> We have noticed these build failures on
>  - stable-4.19
>  - stable-5.4
>  - stable-5.9
>  - mainline
>  - next-master
>
> FYI, The defconfig builds are successful.
> BTW, May I know what are the configs you build often ?

Hi Naresh, thank you again for these reports; they are invaluable.  We
were testing malta_kvm_guest_defconfig for ARCH=mips and ARCH=mipsel.
We should work to get those configs building/tested as well.

"were testing" past tense, because TravisCI just nuked our builds!
https://blog.travis-ci.com/oss-announcement

So we're running with one CI system down at the moment.  I'm working
with Dan on leveraging tuxbuild and github actions.

>
> Steps to reproduce build failure:
> -----------------------------------------
> # sudo pip3 install -U tuxmake
> # tuxmake --runtime docker --target-arch mips --toolchain clang-11
> --kconfig allnoconfig
> # tuxmake --runtime docker --target-arch mips --toolchain clang-11
> --kconfig tinyconfig
>
> Build failed log:
> ake --silent --keep-going --jobs=16
> O=/home/tuxbuild/.cache/tuxmake/builds/2/tmp ARCH=mips
> CROSS_COMPILE=mips-linux-gnu- 'HOSTCC=sccache clang' 'CC=sccache
> clang' allnoconfig
> make --silent --keep-going --jobs=16
> O=/home/tuxbuild/.cache/tuxmake/builds/2/tmp ARCH=mips
> CROSS_COMPILE=mips-linux-gnu- 'HOSTCC=sccache clang' 'CC=sccache
> clang'
> /builds/1kl9SVppm6wRdzlQ3UcQKIBaUrx/arch/mips/vdso/elf.S:14:1:
> warning: DWARF2 only supports one section per compilation unit
> .pushsection .note.Linux, "a",@note ; .balign 4 ; .long 2f - 1f ;
> .long 4484f - 3f ; .long 0 ; 1:.asciz "Linux" ; 2:.balign 4 ; 3:
> ^
> /builds/1kl9SVppm6wRdzlQ3UcQKIBaUrx/arch/mips/vdso/elf.S:34:2:
> warning: DWARF2 only supports one section per compilation unit
>  .section .mips_abiflags, "a"
>  ^

So this is likely the vdso resetting KBUILD_CFLAGS (common issue)
which is dropping -no-integrated-as, but setting -Wa,-gdwarf-2, which
we disabled in the top level Makefile.

> /builds/1kl9SVppm6wRdzlQ3UcQKIBaUrx/arch/mips/lib/uncached.c:45:6:
> warning: variable 'sp' is uninitialized when used here
> [-Wuninitialized]
>         if (sp >= (long)CKSEG0 && sp < (long)CKSEG2)
>             ^~
> /builds/1kl9SVppm6wRdzlQ3UcQKIBaUrx/arch/mips/lib/uncached.c:40:18:
> note: initialize the variable 'sp' to silence this warning
>         register long sp __asm__("$sp");
>                         ^
>                          = 0

I think we recently discussed this upstream.
https://lore.kernel.org/linux-mips/alpine.LFD.2.21.2012061431190.656242@xxxxxxxxxxxxxxxxxxxx/T/#mcaabe339aaee81ed8f6dfe761f699c82e938b4c5

> 1 warning generated.
> WARNING: modpost: vmlinux.o(.text+0x1a124): Section mismatch in
> reference from the function r4k_cache_init() to the function
> .init.text:loongson3_sc_init()
> The function r4k_cache_init() references
> the function __init loongson3_sc_init().
> This is often because r4k_cache_init lacks a __init
> annotation or the annotation of loongson3_sc_init is wrong.
> WARNING: modpost: vmlinux.o(.text+0x1f1c8): Section mismatch in
> reference from the function mips_sc_init() to the function
> .init.text:mips_sc_probe()
> The function mips_sc_init() references
> the function __init mips_sc_probe().
> This is often because mips_sc_init lacks a __init
> annotation or the annotation of mips_sc_probe is wrong.
> FATAL: modpost: Section mismatches detected.
> Set CONFIG_SECTION_MISMATCH_WARN_ONLY=y to allow them.
> make[2]: *** [/builds/1kl9SVppm6wRdzlQ3UcQKIBaUrx/scripts/Makefile.modpost:59:
> vmlinux.symvers] Error 1

Anders sent a patch for this, too, IIRC.  Once the above fixes land
upstream, we probably need to follow up on ensuring they get picked up
into the affected branches of stable.

-- 
Thanks,
~Nick Desaulniers