[PATCH] efi/arm: fix absolute relocation detection for older toolchains

Ard Biesheuvel ard.biesheuvel at linaro.org
Tue Oct 4 03:34:31 PDT 2016


On 3 October 2016 at 13:52, Matt Fleming <matt at codeblueprint.co.uk> 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.



More information about the linux-arm-kernel mailing list