Re: [peterz-queue:sched/urgent 4/5] ld.lld: error: section .text at 0xFFFFFFFF80200000 of size 0x1E8915C exceeds available address space

Linux MIPS Architecture development
 help / color / mirror / Atom feed

* Re: [peterz-queue:sched/urgent 4/5] ld.lld: error: section .text at 0xFFFFFFFF80200000 of size 0x1E8915C exceeds available address space
       [not found]     ` <20200404010210.GA13010@intel.com>
@ 2020-04-04  1:32       ` Fangrui Song
  2020-04-04 13:15         ` Jiaxun Yang
  0 siblings, 1 reply; 7+ messages in thread
From: Fangrui Song @ 2020-04-04  1:32 UTC (permalink / raw)
  To: linux-mips
  Cc: Nathan Chancellor, Nick Desaulniers, Rui Ueyama, George Rimar,
	Sebastian Andrzej Siewior, kbuild-all, clang-built-linux,
	Peter Zijlstra, kbuild test robot, Philip Li


On 2020-04-04, Philip Li wrote:
>On Fri, Apr 03, 2020 at 12:20:58PM -0700, Nathan Chancellor wrote:
>> On Fri, Apr 03, 2020 at 09:37:57AM -0700, 'Nick Desaulniers' via Clang Built Linux wrote:
>> > + Fangrui, Rui, George
>> > The below errors from LLD look new to me, thoughts?
>> >
>> > On Fri, Apr 3, 2020 at 8:42 AM kbuild test robot <lkp@intel.com> wrote:
>> > >
>> > > tree:   https://git.kernel.org/pub/scm/linux/kernel/git/peterz/queue.git sched/urgent
>> > > head:   59d4dade8ccbaa299f5f5dcd775f7a9b7277fb5a
>> > > commit: ae1177617ed17157f29959b0fe4d60f532a5b36e [4/5] workqueue: Remove the warning in wq_worker_sleeping()
>> > > config: mips-randconfig-a001-20200403 (attached as .config)
>> > > compiler: clang version 11.0.0 (https://github.com/llvm/llvm-project f68cc2a7ed766965028b8b0f0d9300a0460c3cf1)
>> > > reproduce:
>> > >         wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
>> > >         chmod +x ~/bin/make.cross
>> > >         git checkout ae1177617ed17157f29959b0fe4d60f532a5b36e
>> > >         # save the attached .config to linux build tree
>> > >         COMPILER=clang make.cross ARCH=mips
>> > >
>> > > If you fix the issue, kindly add following tag
>> > > Reported-by: kbuild test robot <lkp@intel.com>
>> > >
>> > > All errors (new ones prefixed by >>):
>> > >
>> > > >> ld.lld: error: section .text at 0xFFFFFFFF80200000 of size 0x1E8915C exceeds available address space
>> > > >> ld.lld: error: section __ex_table at 0xFFFFFFFF82089160 of size 0x27B0 exceeds available address space
>> > > >> ld.lld: error: section __dbe_table at 0xFFFFFFFF8208B910 of size 0x0 exceeds available address space
>> > >    ld.lld: error: section .rodata at 0xFFFFFFFF8208C000 of size 0x480F81 exceeds available address space
>> > >    ld.lld: error: section .data..page_aligned at 0xFFFFFFFF8250D000 of size 0x2000 exceeds available address space
>> > >    ld.lld: error: section .got at 0xFFFFFFFF8250F000 of size 0x8 exceeds available address space
>> > >    ld.lld: error: section .rodata1 at 0xFFFFFFFF8250F008 of size 0x0 exceeds available address space
>> > >    ld.lld: error: section .pci_fixup at 0xFFFFFFFF8250F008 of size 0x0 exceeds available address space
>> > >    ld.lld: error: section .builtin_fw at 0xFFFFFFFF8250F008 of size 0x0 exceeds available address space
>> > >    ld.lld: error: section __ksymtab at 0xFFFFFFFF8250F008 of size 0x145EC exceeds available address space
>> > >    ld.lld: error: section __ksymtab_gpl at 0xFFFFFFFF825235F4 of size 0x12378 exceeds available address space
>> > >    ld.lld: error: section __ksymtab_unused at 0xFFFFFFFF8253596C of size 0x0 exceeds available address space
>> > >    ld.lld: error: section __ksymtab_unused_gpl at 0xFFFFFFFF8253596C of size 0x0 exceeds available address space
>> > >    ld.lld: error: section __ksymtab_gpl_future at 0xFFFFFFFF8253596C of size 0x0 exceeds available address space
>> > >    ld.lld: error: section __kcrctab at 0xFFFFFFFF8253596C of size 0x0 exceeds available address space
>> > >    ld.lld: error: section __kcrctab_gpl at 0xFFFFFFFF8253596C of size 0x0 exceeds available address space
>> > >    ld.lld: error: section __kcrctab_unused at 0xFFFFFFFF8253596C of size 0x0 exceeds available address space
>> > >    ld.lld: error: section __kcrctab_unused_gpl at 0xFFFFFFFF8253596C of size 0x0 exceeds available address space
>> > >    ld.lld: error: section __kcrctab_gpl_future at 0xFFFFFFFF8253596C of size 0x0 exceeds available address space
>> > >    ld.lld: error: section __ksymtab_strings at 0xFFFFFFFF8253596C of size 0x40CB3 exceeds available address space
>> > >    ld.lld: error: too many errors emitted, stopping now (use -error-limit=0 to see all errors)
>> > >
>> > > ---
>> > > 0-DAY CI Kernel Test Service, Intel Corporation
>> > > https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org
>> > >
>> >
>> >
>> >
>> > --
>> > Thanks,
>> > ~Nick Desaulniers
>> >
>>
>> This is an open issue on our issue tracker:
>>
>> https://github.com/ClangBuiltLinux/linux/issues/786
>>
>> Note that this is a mips-randconfig.
>Thanks, we will temporarily blacklist this error.

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 :/

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [peterz-queue:sched/urgent 4/5] ld.lld: error: section .text at 0xFFFFFFFF80200000 of size 0x1E8915C exceeds available address space
  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
                             ` (2 more replies)
  0 siblings, 3 replies; 7+ messages in thread
From: Jiaxun Yang @ 2020-04-04 13:15 UTC (permalink / raw)
  To: Fangrui Song
  Cc: linux-mips, Nathan Chancellor, Nick Desaulniers, Rui Ueyama,
	George Rimar, Sebastian Andrzej Siewior, kbuild-all,
	clang-built-linux, Peter Zijlstra, kbuild test robot, Philip Li

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

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [peterz-queue:sched/urgent 4/5] ld.lld: error: section .text at 0xFFFFFFFF80200000 of size 0x1E8915C exceeds available address space
  2020-04-04 13:15         ` Jiaxun Yang
@ 2020-04-04 16:19           ` Fangrui Song
  2020-04-04 21:59           ` Nathan Chancellor
  2020-04-06 17:34           ` Nick Desaulniers
  2 siblings, 0 replies; 7+ messages in thread
From: Fangrui Song @ 2020-04-04 16:19 UTC (permalink / raw)
  To: Jiaxun Yang
  Cc: linux-mips, Nathan Chancellor, Nick Desaulniers, Rui Ueyama,
	George Rimar, Sebastian Andrzej Siewior, kbuild-all,
	clang-built-linux, Peter Zijlstra, kbuild test robot, Philip Li

On 2020-04-04, 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

Thanks! The patch fixes the problem linking with LLD.

If you are going to send a patch,

Reviewed-by: Fangrui Song <maskray@google.com>

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [peterz-queue:sched/urgent 4/5] ld.lld: error: section .text at 0xFFFFFFFF80200000 of size 0x1E8915C exceeds available address space
  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
  2020-04-06 17:34           ` Nick Desaulniers
  2 siblings, 1 reply; 7+ messages in thread
From: Nathan Chancellor @ 2020-04-04 21:59 UTC (permalink / raw)
  To: Jiaxun Yang
  Cc: Fangrui Song, linux-mips, Nick Desaulniers, Rui Ueyama,
	George Rimar, Sebastian Andrzej Siewior, kbuild-all,
	clang-built-linux, Peter Zijlstra, kbuild test robot, Philip Li

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>

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [peterz-queue:sched/urgent 4/5] ld.lld: error: section .text at 0xFFFFFFFF80200000 of size 0x1E8915C exceeds available address space
  2020-04-04 21:59           ` Nathan Chancellor
@ 2020-04-05  1:00             ` Philip Li
  2020-04-05  1:39               ` Nathan Chancellor
  0 siblings, 1 reply; 7+ messages in thread
From: Philip Li @ 2020-04-05  1:00 UTC (permalink / raw)
  To: Nathan Chancellor
  Cc: Jiaxun Yang, Fangrui Song, linux-mips, Nick Desaulniers,
	Rui Ueyama, George Rimar, Sebastian Andrzej Siewior, kbuild-all,
	clang-built-linux, Peter Zijlstra, kbuild test robot

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.

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [peterz-queue:sched/urgent 4/5] ld.lld: error: section .text at 0xFFFFFFFF80200000 of size 0x1E8915C exceeds available address space
  2020-04-05  1:00             ` Philip Li
@ 2020-04-05  1:39               ` Nathan Chancellor
  0 siblings, 0 replies; 7+ messages in thread
From: Nathan Chancellor @ 2020-04-05  1:39 UTC (permalink / raw)
  To: Philip Li
  Cc: Jiaxun Yang, Fangrui Song, linux-mips, Nick Desaulniers,
	Rui Ueyama, George Rimar, Sebastian Andrzej Siewior, kbuild-all,
	clang-built-linux, Peter Zijlstra, kbuild test robot

On Sun, Apr 05, 2020 at 09:00:05AM +0800, Philip Li wrote:
> 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.

The error is valid it seems but no commit should be blamed for causing
that error. In other words, it should be fine to un-blacklist it but
emails should not be sent to patch authors if that error is the only
error in the log.

Cheers,
Nathan

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [peterz-queue:sched/urgent 4/5] ld.lld: error: section .text at 0xFFFFFFFF80200000 of size 0x1E8915C exceeds available address space
  2020-04-04 13:15         ` Jiaxun Yang
  2020-04-04 16:19           ` Fangrui Song
  2020-04-04 21:59           ` Nathan Chancellor
@ 2020-04-06 17:34           ` Nick Desaulniers
  2 siblings, 0 replies; 7+ messages in thread
From: Nick Desaulniers @ 2020-04-06 17:34 UTC (permalink / raw)
  To: Jiaxun Yang
  Cc: Fangrui Song, linux-mips, Nathan Chancellor, Rui Ueyama,
	George Rimar, Sebastian Andrzej Siewior, kbuild-all,
	clang-built-linux, Peter Zijlstra, kbuild test robot, Philip Li

On Sat, Apr 4, 2020 at 6:16 AM Jiaxun Yang <jiaxun.yang@flygoat.com> 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?

Hi Jiaxun, can you please send this patch?

>
> --- 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



-- 
Thanks,
~Nick Desaulniers

^ permalink raw reply	[flat|nested] 7+ messages in thread

end of thread, other threads:[~2020-04-06 17:34 UTC | newest]

Thread overview: 7+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
     [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
2020-04-05  1:39               ` Nathan Chancellor
2020-04-06 17:34           ` Nick Desaulniers

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox