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

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

[kbuild test robot]

[-- Attachment #1: Type: text/plain, Size: 3264 bytes --]

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(a)lists.01.org

[-- Attachment #2: config.gz --]
[-- Type: application/gzip, Size: 33559 bytes --]

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

[Nick Desaulniers]

[-- Attachment #1: Type: text/plain, Size: 3921 bytes --]

+ 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(a)lists.01.org
>
> --
> 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-linux+unsubscribe(a)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

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

[Philip Li]

[-- Attachment #1: Type: text/plain, Size: 4157 bytes --]

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(a)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.

> 
> Cheers,
> Nathan
> 

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

[Fangrui Song]

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

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

[Fangrui Song]

[-- Attachment #1: Type: text/plain, Size: 5260 bytes --]


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(a)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 :/

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

[Jiaxun Yang]

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

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

[Fangrui Song]

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>

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

[Fangrui Song]

[-- Attachment #1: Type: text/plain, Size: 1943 bytes --]

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>

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

[Nathan Chancellor]

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>

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

[Philip Li]

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.

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

[Philip Li]

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

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

[Nathan Chancellor]

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

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

[Nick Desaulniers]

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

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

[Nick Desaulniers]

[-- Attachment #1: Type: text/plain, Size: 1977 bytes --]

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