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.
next prev parent reply other threads:[~2020-04-05 1:00 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <202004032329.oBqXCsfi%lkp@intel.com>
[not found] ` <CAKwvOd=H71Q=r=S6Zr=N1zgkXTb9HyEwF78ZbuKkoigWZxiBDA@mail.gmail.com>
[not found] ` <20200403192058.GA41585@ubuntu-m2-xlarge-x86>
[not found] ` <20200404010210.GA13010@intel.com>
2020-04-04 1:32 ` [peterz-queue:sched/urgent 4/5] ld.lld: error: section .text at 0xFFFFFFFF80200000 of size 0x1E8915C exceeds available address space Fangrui Song
2020-04-04 13:15 ` Jiaxun Yang
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:39 ` Nathan Chancellor
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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox