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

[kbuild test robot]

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 <l...@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/kbuil...@lists.01.org

[Nick Desaulniers]

+ Fangrui, Rui, George
The below errors from LLD look new to me, thoughts?

> --
> You received this message because you are subscribed to the Google Groups "Clang Built Linux" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to clang-built-li...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/clang-built-linux/202004032329.oBqXCsfi%25lkp%40intel.com.



--
Thanks,
~Nick Desaulniers

[Nathan Chancellor]

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

Cheers,
Nathan

[Philip Li]

Thanks, we will temporarily blacklist this error.

>
> Cheers,
> Nathan
>

[Fangrui Song]

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

[Jiaxun Yang]

On Fri, 3 Apr 2020 18:32:04 -0700
Fangrui Song <mas...@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

[Fangrui Song]

Thanks! The patch fixes the problem linking with LLD.

If you are going to send a patch,

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

[Nathan Chancellor]

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 <natecha...@gmail.com>

[Philip Li]

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.

[Nathan Chancellor]

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

[Nick Desaulniers]

On Sat, Apr 4, 2020 at 6:16 AM Jiaxun Yang <jiaxu...@flygoat.com> wrote:
>
> On Fri, 3 Apr 2020 18:32:04 -0700
> Fangrui Song <mas...@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