lkml.org 
[lkml]   [2020]   [Jul]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
SubjectRe: 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

\
 
 \ /
  Last update: 2020-07-11 18:04    [W:0.056 / U:0.048 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site