Re: linux-next: Tree for May 15 (several RV64 build errors)

From: Palmer Dabbelt
Date: Wed May 24 2023 - 19:11:11 EST

On Wed, 24 May 2023 15:49:41 PDT (-0700), Conor Dooley wrote:
On Wed, May 24, 2023 at 03:41:15PM -0700, Randy Dunlap wrote:
On 5/23/23 23:23, Arnd Bergmann wrote:
> On Wed, May 24, 2023, at 03:29, Palmer Dabbelt wrote:
>> On Tue, 23 May 2023 17:22:20 PDT (-0700), rdunlap@xxxxxxxxxxxxx wrote:
>>> On 5/23/23 06:07, Alexandre Ghiti wrote:
>>>> On 23/05/2023 04:28, Randy Dunlap wrote:
>>>>> On 5/19/23 03:42, Alexandre Ghiti wrote:
>>>>>>>> /opt/crosstool/gcc-12.2.0-nolibc/riscv64-linux/bin/riscv64-linux-ld: section .data LMA [000000000041a000,00000000075bffd7] overlaps section .text LMA [00000000000f09d4,00000000033562ab]
>>>>>>>> /opt/crosstool/gcc-12.2.0-nolibc/riscv64-linux/bin/riscv64-linux-ld: section .init.pi.text LMA [00000000033562ac,0000000003359137] overlaps section .data LMA [000000000041a000,00000000075bffd7]
>>>>>>> I'll check this one too which seems to be related to kernel/pi introduction.
>>>>>> Thanks to Bjorn: this is caused by XIP_KERNEL, which is known to have limited size, hence the overlap, so no fix for this one. Is there a way to exclude this config from randconfig?
>>>>> Does this mean exclude XIP_KERNEL or something else from randconfigs?
>>>> I meant excluding XIP_KERNEL from randconfigs: it has very strict constraints regarding what can/can't be enabled then it needs human intervention to make sure the error above does not happen. So I would not bother testing this in randconfigs if possible.
>>> I can exclude it from my randconfig builds, but I don't know of a way to exclude it from randconfig builds in general (i.e., for everyone).
>> Arnd had suggested a trick related to menus that would result in >> randconfig never enabling some config. It'd suggested for >> CONFIG_NONPORTABLE, but we didn't use it because it'd reduce randconfig >> coverage.
>> Maybe we should add a CONFIG_VERYSPECIAL of some sort and hide things >> like XIP behind it (maybe M-mode too)?
> > I usually add 'depends on !COMPILE_TEST', that excludes it from most
> build bots.

XIP_KERNEL already has "depends on !COMPILE_TEST", since April of 2021.

Half of me wants to say just remove XIP_KERNEL entirely. Or make it
depend on BROKEN, since noone seems to actually test it and I don't
think we even know if it works right now?

Ya, let's do it. If it's broken and nobody has said anything but randconfig, then probably nobody's using it. Let's mark it as broken or deprecated or whatever and then see if anyone complains.