more RELOCATABLE + errata code model issues

[Alexandre Ghiti]

On 18/09/2023 17:15, Palmer Dabbelt wrote:
> On Mon, 18 Sep 2023 03:36:03 PDT (-0700), Conor Dooley wrote:
>>
>> Hey Alex,
>>
>> LKP reported [1] some issues with relocatable kernels & code models.
>> You didn't touch the commit that caused the issues, so you didn't see
>> the failure report I guess, but Prabhakar is looking for some guidance
>> on what he should do to resolve the problems. Copy-pasting from his
>> mail:
>>> > All errors (new ones prefixed by >>):
>>> > > >> ld.lld: error: relocation R_RISCV_LO12_I cannot be used against
>>> > >> symbol 'riscv_cbom_block_size'; recompile with -fPIC
>>> >    >>> defined in vmlinux.a(arch/riscv/mm/cacheflush.o)
>>> >    >>> referenced by errata.c
>>> >    >>> arch/riscv/errata/andes/errata.o:(andes_errata_patch_func) 
>>> in archive vmlinux.a
>>> > I did reproduce this issue locally. The andes errata is not 
>>> compiled as medany. The config is RELOCATABLE + MEDLOW. I can see 
>>> the cacheflush.o is compiled with medany flag.
>>> I can fix the build by adding a medany flag as below:
>>> +#ifdef CONFIG_RISCV_ALTERNATIVE_EARLY
>>> +CFLAGS_errata.o := -mcmodel=medany
>>> #endif
>>>
>>> But I am not sure if this is correct approach. Any pointers on this?
>>
>> The T-Head errata have something similar, so seems like fair game to me.
>> Any thoughts?
>
> We're using medany as a cheap way to get PIC, so anything that's 
> pre-relocation will need medany.  We don't really have a good way to 
> check that, medany isn't supposed to be ABI (we're really just abusing 
> it here for PIC).  Thus none of this gets checked at build time, and I 
> won't catch any errata pre-merge because I'm in QEMU. So this is all 
> kind of fragile.
>
> So maybe there's a better way to do all that, but for now just adding 
> medany seems like the way to go.


There is the pre-mmu documentation now that gives hint about what to do 
for the very early code: 
https://elixir.bootlin.com/linux/v6.6-rc2/source/Documentation/riscv/boot.rst#L151 
but admittedly, it does not state that it would result in compilation 
errors, maybe that can be added.


>
>> Thanks,
>> Conor.
>>
>> [1] - https://lore.kernel.org/all/202309111311.8tcq3KVc-lkp@intel.com/
>
> _______________________________________________
> linux-riscv mailing list
> linux-riscv at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-riscv