From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-7.2 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,MENTIONS_GIT_HOSTING,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED, USER_AGENT_SANE_1 autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 25A28C2BA15 for ; Sun, 5 Apr 2020 01:00:40 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id E8AC5206D4 for ; Sun, 5 Apr 2020 01:00:39 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726283AbgDEBAj (ORCPT ); Sat, 4 Apr 2020 21:00:39 -0400 Received: from mga07.intel.com ([134.134.136.100]:19274 "EHLO mga07.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726057AbgDEBAj (ORCPT ); Sat, 4 Apr 2020 21:00:39 -0400 IronPort-SDR: w2TNcq8ppV/Ws832tN1u9kyphEmsqq4/+lyOrRNr4jgxsoYgXmDpe+GpBNVZWab5OYlmPqQqQu IF0/upNGX17A== X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga007.jf.intel.com ([10.7.209.58]) by orsmga105.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 04 Apr 2020 18:00:38 -0700 IronPort-SDR: KTdevKEGBgLUFVjLvH6eBiaL7Ro9iATH9nQ7Lr7gzr7z7F9rmo4wcPY/VJWYBKtqOm8TqlT0+E GUqdwWK+blyg== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.72,345,1580803200"; d="scan'208";a="239252078" Received: from unknown (HELO intel.com) ([10.239.159.39]) by orsmga007.jf.intel.com with ESMTP; 04 Apr 2020 18:00:35 -0700 Date: Sun, 5 Apr 2020 09:00:05 +0800 From: Philip Li To: Nathan Chancellor Cc: Jiaxun Yang , Fangrui Song , linux-mips@vger.kernel.org, Nick Desaulniers , Rui Ueyama , George Rimar , Sebastian Andrzej Siewior , kbuild-all@lists.01.org, clang-built-linux , Peter Zijlstra , kbuild test robot Subject: Re: [peterz-queue:sched/urgent 4/5] ld.lld: error: section .text at 0xFFFFFFFF80200000 of size 0x1E8915C exceeds available address space Message-ID: <20200405010005.GA18493@intel.com> References: <202004032329.oBqXCsfi%lkp@intel.com> <20200403192058.GA41585@ubuntu-m2-xlarge-x86> <20200404010210.GA13010@intel.com> <20200404013204.p53fteofnppvf7pe@google.com> <20200404211252.3540251a@flygoat-x1e> <20200404215916.GA929@ubuntu-m2-xlarge-x86> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200404215916.GA929@ubuntu-m2-xlarge-x86> User-Agent: Mutt/1.10.1 (2018-07-13) Sender: linux-mips-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-mips@vger.kernel.org On Sat, Apr 04, 2020 at 02:59:16PM -0700, Nathan Chancellor wrote: > On Sat, Apr 04, 2020 at 09:15:31PM +0800, Jiaxun Yang wrote: > > On Fri, 3 Apr 2020 18:32:04 -0700 > > Fangrui Song wrote: > > > > > > > > Reproduce for a clang/lld developer: > > > > > > make -j$(nproc) ARCH=mips CC=clang CROSS_COMPILE=mipsel-linux-gnu- > > > LD=ld.lld O=/tmp/out/mipsel distclean malta_defconfig vmlinux > > > (Requires mipsel-linux-gnu-as and clang in PATH) > > > > > > I have noticed multiple problems. > > > > > > % file .tmp_vmlinux.kallsyms1 > > > .tmp_vmlinux.kallsyms1: ELF 32-bit LSB executable, MIPS, MIPS32 rel2 > > > version 1 (SYSV), statically linked, > > > BuildID[sha1]=ff348ad92c80e525b3f14149e57e8987de66e041, not stripped > > > > > > In arch/mips/kernel/vmlinux.lds.S, VMLINUX_LOAD_ADDRESS (from load-y) > > > is 0xffffffff8010000. GNU ld seems to allow 64-bit addresses when > > > linking an ELFCLASS32 file. The addresses will be truncated to > > > 32-bit. This behavior seems error-prone to me. > > > > > > lld does the right thing by erroring out. I do notice a display > > > problem of lld -Map and I have a patch to address that: > > > https://reviews.llvm.org/D77445 > > > > > > For 32-bit linux-mips, the right approach seems to be make > > > VMLINUX_LOAD_ADDRESS fit into 32-bit. However, my Linux-fu and > > > MIPS-fu is not strong enough to do this :/ > > > > Hi MaskRay, > > > > Could you please try this? > > > > --- a/arch/mips/mti-malta/Platform > > +++ b/arch/mips/mti-malta/Platform > > @@ -6,6 +6,10 @@ cflags-$(CONFIG_MIPS_MALTA) += > > -I$(srctree)/arch/mips/include/asm/mach-malta ifdef CONFIG_KVM_GUEST > > load-$(CONFIG_MIPS_MALTA) += 0x0000000040100000 > > else > > +ifdef CONFIG_64BIT > > load-$(CONFIG_MIPS_MALTA) += 0xffffffff80100000 > > +else > > + load-$(CONFIG_MIPS_MALTA) += 0x80100000 > > +endif > > endif > > all-$(CONFIG_MIPS_MALTA) := $(COMPRESSION_FNAME).bin > > > > Thanks. > > > > -- > > Jiaxun Yang > > Thank you, that fixes the error and I see no new ones. I tested > malta_defconfig, which boots in QEMU: > > Linux version 5.6.0-next-20200404-dirty (nathan@ubuntu-m2-xlarge-x86) (ClangBuiltLinux clang version 11.0.0 (git://github.com/llvm/llvm-project 1ce0bc39eebe95a350174eb0ed4e2508e7cb6ed8), LLD 11.0.0 (git://github.com/llvm/llvm-project 1ce0bc39eebe95a350174eb0ed4e2508e7cb6ed8)) #1 SMP Sat Apr 4 14:54:45 MST 2020 > > Tested-by: Nathan Chancellor Hi all, want to consult, does it mean 0-day ci doesn't need blacklist this ld.lld error anymore? This is a kernel problem and the error itself is valid. From mboxrd@z Thu Jan 1 00:00:00 1970 Content-Type: multipart/mixed; boundary="===============6935821696765236928==" MIME-Version: 1.0 From: Philip Li To: kbuild-all@lists.01.org Subject: Re: [peterz-queue:sched/urgent 4/5] ld.lld: error: section .text at 0xFFFFFFFF80200000 of size 0x1E8915C exceeds available address space Date: Sun, 05 Apr 2020 09:00:05 +0800 Message-ID: <20200405010005.GA18493@intel.com> In-Reply-To: <20200404215916.GA929@ubuntu-m2-xlarge-x86> List-Id: --===============6935821696765236928== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable On Sat, Apr 04, 2020 at 02:59:16PM -0700, Nathan Chancellor wrote: > On Sat, Apr 04, 2020 at 09:15:31PM +0800, Jiaxun Yang wrote: > > On Fri, 3 Apr 2020 18:32:04 -0700 > > Fangrui Song wrote: > > = > > > = > > > Reproduce for a clang/lld developer: > > > = > > > make -j$(nproc) ARCH=3Dmips CC=3Dclang CROSS_COMPILE=3Dmipsel-linux-g= nu- > > > LD=3Dld.lld O=3D/tmp/out/mipsel distclean malta_defconfig vmlinux > > > (Requires mipsel-linux-gnu-as and clang in PATH) > > > = > > > I have noticed multiple problems. > > > = > > > % file .tmp_vmlinux.kallsyms1 > > > .tmp_vmlinux.kallsyms1: ELF 32-bit LSB executable, MIPS, MIPS32 rel2 > > > version 1 (SYSV), statically linked, > > > BuildID[sha1]=3Dff348ad92c80e525b3f14149e57e8987de66e041, not stripped > > > = > > > In arch/mips/kernel/vmlinux.lds.S, VMLINUX_LOAD_ADDRESS (from load-y) > > > is 0xffffffff8010000. GNU ld seems to allow 64-bit addresses when > > > linking an ELFCLASS32 file. The addresses will be truncated to > > > 32-bit. This behavior seems error-prone to me. > > > = > > > lld does the right thing by erroring out. I do notice a display > > > problem of lld -Map and I have a patch to address that: > > > https://reviews.llvm.org/D77445 > > > = > > > For 32-bit linux-mips, the right approach seems to be make > > > VMLINUX_LOAD_ADDRESS fit into 32-bit. However, my Linux-fu and > > > MIPS-fu is not strong enough to do this :/ > > = > > Hi MaskRay, > > = > > Could you please try this? > > = > > --- a/arch/mips/mti-malta/Platform > > +++ b/arch/mips/mti-malta/Platform > > @@ -6,6 +6,10 @@ cflags-$(CONFIG_MIPS_MALTA) +=3D > > -I$(srctree)/arch/mips/include/asm/mach-malta ifdef CONFIG_KVM_GUEST > > load-$(CONFIG_MIPS_MALTA) +=3D 0x0000000040100000 > > else > > +ifdef CONFIG_64BIT > > load-$(CONFIG_MIPS_MALTA) +=3D 0xffffffff80100000 > > +else > > + load-$(CONFIG_MIPS_MALTA) +=3D 0x80100000 > > +endif > > endif > > all-$(CONFIG_MIPS_MALTA) :=3D $(COMPRESSION_FNAME).bin > > = > > Thanks. > > = > > -- > > Jiaxun Yang > = > Thank you, that fixes the error and I see no new ones. I tested > malta_defconfig, which boots in QEMU: > = > Linux version 5.6.0-next-20200404-dirty (nathan(a)ubuntu-m2-xlarge-x86) (= ClangBuiltLinux clang version 11.0.0 (git://github.com/llvm/llvm-project 1c= e0bc39eebe95a350174eb0ed4e2508e7cb6ed8), LLD 11.0.0 (git://github.com/llvm/= llvm-project 1ce0bc39eebe95a350174eb0ed4e2508e7cb6ed8)) #1 SMP Sat Apr 4 14= :54:45 MST 2020 > = > Tested-by: Nathan Chancellor Hi all, want to consult, does it mean 0-day ci doesn't need blacklist this ld.lld error anymore? This is a kernel problem and the error itself is valid. --===============6935821696765236928==--