On 3 October 2016 at 13:52, Matt Fleming <matt@xxxxxxxxxxxxxxxxxxx> wrote: > On Fri, 30 Sep, at 04:01:55PM, Ard Biesheuvel wrote: >> >> This is a workaround for now. We can revisit this when a need arises to copy >> more kernel code into the stub, by which time we could put in a more elaborate >> fix, or decide to no longer care about 'older' versions of objcopy. >> >> Since this fixes an ARM specific issue and only affects ARM specific Makefile >> variables, I am happy for this to go on top of the arm-soc patch that enables >> CONFIG_EFI for ARM's multi_v7_defconfig (queued for v4.9), given that we have >> no other changes queued in linux-efi that should conflict with this patch. >> >> Matt, any concerns? > > Not with the patch, but could we clarify the user-visible effects of > not applying it? Are the absolute relocations harmless, or will they > lead to crashes? These relocations are harmless, since the debug ones are only interpreted by the debugger, and the ones generated by EXPORT_SYMBOL(sort) will never be referenced, since the symbols they contain are either renamed to __efistub_xxx (arm64), or they are not part of the kernel proper (arm) So both cases are false positives, but the diagnostic is important, and so breaking the build is appropriate for any other absolute relocation that may appear. The effect of the patch is not that the diagnostic is ignored, but that these relocations are not generated in the first place (-g0) or removed explicitly (ksymtab/krcrctab+sort) rather than via a wildcard. So other than not breaking the build, this patch should have no user observeable differences. -- Ard. -- To unsubscribe from this list: send the line "unsubscribe linux-efi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
