Messages in this thread | | | From | Arnd Bergmann <> | Date | Sat, 11 Jul 2020 18:03:17 +0200 | Subject | Re: arm-linux-gnueabi-ld: section .rodata VMA overlaps section .bss VMA |
| |
On Sat, Jul 11, 2020 at 5:00 PM Ard Biesheuvel <ardb@kernel.org> wrote: > On Sat, 11 Jul 2020 at 15:30, Russell King - ARM Linux admin > <linux@armlinux.org.uk> wrote: > > > > I doubt anyone is going to fix this; it's an XIP kernel, and it looks > > like the .data and .rodata sections are correctly placed as per the > > configuration, but for some reason the .text (and sections that follow) > > are incorrectly placed in VMA space. The configuration file says that > > the kernel should start at 0x00080000, and there's no way the .text > > VMA should be starting at 0x3f0801a0. > > > > Note that only one of those lines has the >> prefix, and so this > config was broken even before this patch got applied. > > > Unless one of the XIP using folk can debug this, I doubt there will be > > any movement on it. Especially as it's 5 months old... > > > > What do we do with bugs like this that people won't fix? Remove XIP > > support from the kernel? > > > > I fail to see the point of randconfig testing for xip kernels tbh, and > i don't think it is fair to disable xip altogether if the configs that > those people care about still build as expected. > > But it would indeed be nice if we could at least get rid of these > pointless build reports. Is there any way we can avoid xip from being > selected by randconfig?
In my randconfig builds, I have a patch that makes CONFIG_XIP_KERNEL and some other options depend on '!COMPILE_TEST', and I always enable COMPILE_TEST for randconfig builds. I don't know whether that would work for the kernel test robot as well.
Arnd
| |