[PATCH v5sub2 1/8] arm64: add support for module PLTs

Ard Biesheuvel ard.biesheuvel at linaro.org
Thu Feb 25 08:49:37 PST 2016


On 25 February 2016 at 17:46, Will Deacon <will.deacon at arm.com> wrote:
> On Thu, Feb 25, 2016 at 05:43:35PM +0100, Ard Biesheuvel wrote:
>> On 25 February 2016 at 17:42, Will Deacon <will.deacon at arm.com> wrote:
>> > On Thu, Feb 25, 2016 at 05:33:25PM +0100, Ard Biesheuvel wrote:
>> >> AFAIK, gcc never uses x18 (the platform register) so we may be able to
>> >> use that instead. We'd need confirmation from the toolchain guys,
>> >> though ...
>> >
>> > In fact, a better thing to do is probably for the atomic code to
>> > save/restore those register explicitly and then remove them from the
>> > cflags above.
>> >
>> > I'll try hacking something together...
>> >
>>
>> That would be more correct, indeed. Also, the PLT can only use br
>> <reg> so it will always enter the callee with the preserved value
>> stacked, and so the callee needs to be modified in any case.
>
> Wait -- why does the callee need to be modified here? It has no idea
> about whether or not it was invoked via a PLT.
>

No, it doesn't, and that is exactly the problem: the PLT must end in a
br <reg> instruction because that is the only branch instruction with
unlimited range. That means you will always enter the callee with its
address in some register rather than the value that should have been
preserved. I don't see a way to manage that from the callee

> Also, can I rely on the PLT not clobbering the condition code?
>

For my particular implementation, yes.



More information about the linux-arm-kernel mailing list