Re: arm-linux-gnueabi-ld: section .rodata VMA overlaps section .bss VMA

[Ard Biesheuvel]

On Sat, 11 Jul 2020 at 19:03, Arnd Bergmann <arnd@xxxxxxxx> wrote:
>
> On Sat, Jul 11, 2020 at 5:00 PM Ard Biesheuvel <ardb@xxxxxxxxxx> wrote:
> > On Sat, 11 Jul 2020 at 15:30, Russell King - ARM Linux admin
> > <linux@xxxxxxxxxxxxxxx> 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.
>
>

Both changes sound like things we might simply upstream, no?
Randconfig is only intended for compile testing anyway, and making xip
depend on !COMPILE_TEST seems uncontroversial to me as well.