* [peterz-queue:sched/urgent 4/5] ld.lld: error: section .text at 0xFFFFFFFF80200000 of size 0x1E8915C exceeds available address space
@ 2020-04-03 15:42 kbuild test robot
2020-04-03 16:37 ` Nick Desaulniers
0 siblings, 1 reply; 14+ messages in thread
From: kbuild test robot @ 2020-04-03 15:42 UTC (permalink / raw)
To: kbuild-all
[-- 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 --]
^ permalink raw reply [flat|nested] 14+ 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-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>
0 siblings, 1 reply; 14+ messages in thread
From: Nick Desaulniers @ 2020-04-03 16:37 UTC (permalink / raw)
To: kbuild-all
[-- 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
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [peterz-queue:sched/urgent 4/5] ld.lld: error: section .text at 0xFFFFFFFF80200000 of size 0x1E8915C exceeds available address space
[not found] ` <20200403192058.GA41585@ubuntu-m2-xlarge-x86>
@ 2020-04-04 1:02 ` Philip Li
2020-04-04 1:32 ` Fangrui Song
0 siblings, 1 reply; 14+ messages in thread
From: Philip Li @ 2020-04-04 1:02 UTC (permalink / raw)
To: kbuild-all
[-- 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
>
^ permalink raw reply [flat|nested] 14+ 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:02 ` Philip Li
@ 2020-04-04 1:32 ` Fangrui Song
0 siblings, 0 replies; 14+ 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] 14+ 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 ` Fangrui Song
0 siblings, 0 replies; 14+ messages in thread
From: Fangrui Song @ 2020-04-04 1:32 UTC (permalink / raw)
To: kbuild-all
[-- 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 :/
^ permalink raw reply [flat|nested] 14+ 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 ` Fangrui Song
(?)
@ 2020-04-04 13:15 ` Jiaxun Yang
2020-04-04 16:19 ` Fangrui Song
` (2 more replies)
-1 siblings, 3 replies; 14+ 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] 14+ 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; 14+ 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] 14+ 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 16:19 ` Fangrui Song
0 siblings, 0 replies; 14+ messages in thread
From: Fangrui Song @ 2020-04-04 16:19 UTC (permalink / raw)
To: kbuild-all
[-- 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>
^ permalink raw reply [flat|nested] 14+ 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; 14+ 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] 14+ 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
0 siblings, 0 replies; 14+ 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] 14+ 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
0 siblings, 0 replies; 14+ messages in thread
From: Philip Li @ 2020-04-05 1:00 UTC (permalink / raw)
To: kbuild-all
[-- 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.
^ permalink raw reply [flat|nested] 14+ 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
-1 siblings, 0 replies; 14+ 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] 14+ 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-06 17:34 ` Nick Desaulniers
2020-04-04 21:59 ` Nathan Chancellor
2020-04-06 17:34 ` Nick Desaulniers
2 siblings, 0 replies; 14+ 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] 14+ 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-06 17:34 ` Nick Desaulniers
0 siblings, 0 replies; 14+ messages in thread
From: Nick Desaulniers @ 2020-04-06 17:34 UTC (permalink / raw)
To: kbuild-all
[-- 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
^ permalink raw reply [flat|nested] 14+ messages in thread
end of thread, other threads:[~2020-04-06 17:34 UTC | newest]
Thread overview: 14+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
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
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
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.