Received-SPF: pass (google.com: domain of linux-kernel+bounces-145998-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:4601:e00::3 as permitted sender) client-ip=2604:1380:4601:e00::3;
From: Ammar Faizi <ammarfaizi2@gnuweeb.org>
To: Nathan Chancellor <nathan@kernel.org>
Cc: Ammar Faizi <ammarfaizi2@gnuweeb.org>,
	Memet Zx <zxce3@gnuweeb.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	LLVM Mailing List <llvm@lists.linux.dev>,
	GNU/Weeb Mailing List <gwml@vger.gnuweeb.org>,
	Nick Desaulniers <ndesaulniers@google.com>
Subject: Re: Compile Error in Linux 6.9-rc4 with Clang 17.0.6
Date: Tue, 16 Apr 2024 06:16:22 +0700
Message-Id: <555ac4427590d16c@cgk003-biznet-home.gnuweeb.org>
In-Reply-To: <20240415220626.GA77369@dev-arch.thelio-3990X>
References: <20240415193152.61118-1-zxce3@gnuweeb.org> <20240415220626.GA77369@dev-arch.thelio-3990X>
Precedence: bulk
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

On Mon, 15 Apr 2024 15:06:26 -0700, Nathan Chancellor wrote:
> Thanks for the report. Unfortunately, I cannot reproduce this with your
> configuration on 6.9-rc4 with either kernel.org LLVM 17.0.6 [1] or
> Debian LLVM 17.0.6 [2]. Is this completely reproducible on your side? Is
> this something that just started happening with the 6.9 cycle? What is
> your build command, as I might just be missing something?
> 
> [1]: https://mirrors.edge.kernel.org/pub/tools/llvm/
> [2]: ++20231208085813+6009708b4367-1~exp1~20231208085906.81, should be
>      the same source version and configuration you are using.

Hi,

Thank you for your response!

I am here to respond on behalf of Memet Zx.

I was following Memet's build before he reported this issue. I tried
to reproduce the error on my server, but I couldn't reproduce it as
well. It seems the error is specific to Memet's environment.

FWIW, my build commands are as follows:
```
  wget https://apt.llvm.org/llvm.sh -O /tmp/llvm.sh;
  sudo bash /tmp/llvm.sh 17;
  sudo update-alternatives --install /usr/bin/clang++ clang++ /usr/bin/clang++-17 400;
  sudo update-alternatives --install /usr/bin/clang clang /usr/bin/clang-17 400;

  export LLVM=-17;
  export LLVM_IAS=1;

  # Fill .config file with Memet's config file.

  make -j$(nproc) olddefconfig;
  make -j$(nproc) bindeb-pkg;
```

The steps above are the same as Memet's, but I didn't face the issue.
So yeah, it seems to be specific to Memet's environment. I'll discuss
this further with Memet off-list.

My server survived in the OBJCOPY step, unlike Memet's, and it
finished the debian packaging without fatal errors (despite it shows
warnings):

```
    GEN     .tmp_initcalls.lds
    LD      vmlinux.o
  ld.lld-17: warning: lib/maple_tree.c:4162:0: stack frame size (1040) exceeds limit (1024) in function 'mas_wr_modify'
  ld.lld-17: warning: arch/x86/kvm/hyperv.c:2002:0: stack frame size (1320) exceeds limit (1024) in function 'kvm_hv_flush_tlb'
  ld.lld-17: warning: drivers/infiniband/sw/siw/siw_qp_tx.c:1019:0: stack frame size (1192) exceeds limit (1024) in function 'siw_qp_sq_process'
  ld.lld-17: warning: fs/select.c:976:0: stack frame size (1080) exceeds limit (1024) in function 'do_sys_poll'
  ld.lld-17: warning: drivers/net/wireless/ath/ath9k/ar9003_paprd.c:918:0: stack frame size (1064) exceeds limit (1024) in function 'ar9003_paprd_create_curve'
  ld.lld-17: warning: drivers/net/wireguard/allowedips.c:259:0: stack frame size (1128) exceeds limit (1024) in function 'wg_allowedips_free'
  ld.lld-17: warning: drivers/net/wireguard/allowedips.c:57:0: stack frame size (1080) exceeds limit (1024) in function 'root_free_rcu'
  ld.lld-17: warning: drivers/gpu/drm/radeon/radeon_cs.c:670:0: stack frame size (1152) exceeds limit (1024) in function 'radeon_cs_ioctl'
  ld.lld-17: warning: drivers/edac/sb_edac.c:3078:0: stack frame size (1032) exceeds limit (1024) in function 'sbridge_mce_output_error'
  ld.lld-17: warning: drivers/crypto/ccp/ccp-ops.c:633:0: stack frame size (1032) exceeds limit (1024) in function 'ccp_run_aes_gcm_cmd'
  ld.lld-17: warning: drivers/virtio/virtio_balloon.c:493:0: stack frame size (1064) exceeds limit (1024) in function 'update_balloon_stats_func'
  ld.lld-17: warning: drivers/virtio/virtio_balloon.c:530:0: stack frame size (1224) exceeds limit (1024) in function 'init_vqs'
  ld.lld-17: warning: lib/zstd/compress/huf_compress.c:219:0: stack frame size (1336) exceeds limit (1024) in function 'HUF_readCTable'
  ld.lld-17: warning: drivers/xen/gntdev.c:991:0: stack frame size (1048) exceeds limit (1024) in function 'gntdev_ioctl'
  ld.lld-17: warning: drivers/mtd/nftlcore.c:675:0: stack frame size (1064) exceeds limit (1024) in function 'nftl_writeblock'
  vmlinux.o: warning: objtool: __svm_vcpu_run+0x13c: BP used as a scratch register
  vmlinux.o: warning: objtool: __svm_sev_es_vcpu_run+0x32: BP used as a scratch register
  vmlinux.o: warning: objtool: ip_vs_protocol_init() falls through to next function __initstub__kmod_ip_vs_rr__969_123_ip_vs_rr_init6()
  vmlinux.o: warning: objtool: .text.jffs2_erase_pending_blocks: unexpected end of section
  vmlinux.o: warning: objtool: .text.ocfs2_validate_and_adjust_move_goal: unexpected end of section
  vmlinux.o: warning: objtool: .text.__ocfs2_move_extents_range: unexpected end of section
  vmlinux.o: warning: objtool: .text.csio_ln_fdmi_rhba_cbfn: unexpected end of section
  vmlinux.o: warning: objtool: .text.jme_check_link: unexpected end of section
  vmlinux.o: warning: objtool: .text.vhci_coredump_hdr: unexpected end of section
    OBJCOPY modules.builtin.modinfo
    GEN     modules.builtin
    MODPOST vmlinux.symvers
    UPD     include/generated/utsversion.h
    CC      init/version-timestamp.o
    LD      .tmp_vmlinux.kallsyms1
    NM      .tmp_vmlinux.kallsyms1.syms
    KSYMS   .tmp_vmlinux.kallsyms1.S
    AS      .tmp_vmlinux.kallsyms1.S
    LD      .tmp_vmlinux.kallsyms2
    NM      .tmp_vmlinux.kallsyms2.syms
    KSYMS   .tmp_vmlinux.kallsyms2.S
    AS      .tmp_vmlinux.kallsyms2.S
    LD      vmlinux
```

We will send a follow up if we find that it's related to LLVM. But for
now let's assume something is wrong with Memet's server environment.

Thank you!

-- 
Ammar Faizi