On Thu, 1 Jun 2023 at 16:36, Masahiro Yamada <masahiroy@xxxxxxxxxx> wrote: > > On Thu, Jun 1, 2023 at 9:40 PM Ard Biesheuvel <ardb@xxxxxxxxxx> wrote: > > > > On Thu, 1 Jun 2023 at 14:10, Masahiro Yamada <masahiroy@xxxxxxxxxx> wrote: > > > > > > For ARM, modpost fails to detect some types of section mismatches. > > > > > > [test code] > > > > > > .section .init.data,"aw" > > > bar: > > > .long 0 > > > > > > .section .data,"aw" > > > .globl foo > > > foo: > > > .long bar - . > > > > > > It is apparently a bad reference, but modpost does not report anything. > > > > > > The test code above produces the following relocations. > > > > > > Relocation section '.rel.data' at offset 0xe8 contains 1 entry: > > > Offset Info Type Sym.Value Sym. Name > > > 00000000 00000403 R_ARM_REL32 00000000 .init.data > > > > > > Currently, R_ARM_REL32 is just skipped. > > > > > > Handle it like R_ARM_ABS32. > > > > OK, so the reason we can handle these in the same way is because we > > never calculate the resulting value, right? Because that value would > > be different for these cases. > > Right. > > '- loc' is unnecessary here because modpost never calculates the > resulting instruction. > > modpost wants to know the location of the referenced symbol. > (the offset from the start of the section). > > For the same reason, I omitted '- loc' for > PC-relative ones such as R_ARM_CALL, R_ARM_JUMP24, etc. > OK makes sense - I just wanted to double check
