From: Philip Li <philip.li@intel.com>
To: Nathan Chancellor <natechancellor@gmail.com>
Cc: Jiaxun Yang <jiaxun.yang@flygoat.com>,
Fangrui Song <maskray@google.com>,
linux-mips@vger.kernel.org,
Nick Desaulniers <ndesaulniers@google.com>,
Rui Ueyama <ruiu@google.com>,
George Rimar <grimar@accesssoftek.com>,
Sebastian Andrzej Siewior <bigeasy@linutronix.de>,
kbuild-all@lists.01.org,
clang-built-linux <clang-built-linux@googlegroups.com>,
Peter Zijlstra <peterz@infradead.org>,
kbuild test robot <lkp@intel.com>
Subject: Re: [peterz-queue:sched/urgent 4/5] ld.lld: error: section .text at 0xFFFFFFFF80200000 of size 0x1E8915C exceeds available address space
Date: Sun, 5 Apr 2020 09:00:05 +0800 [thread overview]
Message-ID: <20200405010005.GA18493@intel.com> (raw)
In-Reply-To: <20200404215916.GA929@ubuntu-m2-xlarge-x86>
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 <maskray@google.com> 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 <natechancellor@gmail.com>
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.
WARNING: multiple messages have this Message-ID (diff)
From: Philip Li <philip.li@intel.com>
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 [thread overview]
Message-ID: <20200405010005.GA18493@intel.com> (raw)
In-Reply-To: <20200404215916.GA929@ubuntu-m2-xlarge-x86>
[-- Attachment #1: Type: text/plain, Size: 2711 bytes --]
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 <maskray@google.com> 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(a)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 <natechancellor@gmail.com>
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.
next prev parent reply other threads:[~2020-04-05 1:00 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-04-03 15:42 [peterz-queue:sched/urgent 4/5] ld.lld: error: section .text at 0xFFFFFFFF80200000 of size 0x1E8915C exceeds available address space kbuild test robot
2020-04-03 16:37 ` Nick Desaulniers
[not found] ` <20200403192058.GA41585@ubuntu-m2-xlarge-x86>
2020-04-04 1:02 ` Philip Li
2020-04-04 1:32 ` Fangrui Song
2020-04-04 1:32 ` Fangrui Song
2020-04-04 13:15 ` Jiaxun Yang
2020-04-04 16:19 ` Fangrui Song
2020-04-04 16:19 ` Fangrui Song
2020-04-04 21:59 ` Nathan Chancellor
2020-04-05 1:00 ` Philip Li [this message]
2020-04-05 1:00 ` Philip Li
2020-04-05 1:39 ` Nathan Chancellor
2020-04-06 17:34 ` Nick Desaulniers
2020-04-06 17:34 ` Nick Desaulniers
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20200405010005.GA18493@intel.com \
--to=philip.li@intel.com \
--cc=bigeasy@linutronix.de \
--cc=clang-built-linux@googlegroups.com \
--cc=grimar@accesssoftek.com \
--cc=jiaxun.yang@flygoat.com \
--cc=kbuild-all@lists.01.org \
--cc=linux-mips@vger.kernel.org \
--cc=lkp@intel.com \
--cc=maskray@google.com \
--cc=natechancellor@gmail.com \
--cc=ndesaulniers@google.com \
--cc=peterz@infradead.org \
--cc=ruiu@google.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.