[PATCH] D36749: [LLD][ELF][AArch64] Complete implementation of -fix-cortex-a53-843419

Peter Smith via llvm-commits llvm-commits at lists.llvm.org
Mon Dec 11 08:31:43 PST 2017


On 9 December 2017 at 02:40, Rafael Avila de Espindola
<rafael.espindola at gmail.com> wrote:
> Peter Smith via Phabricator <reviews at reviews.llvm.org> writes:
>
>> The alternative to changing the target of the Thunk is to modify RelExpr, such as what is done for PLT generation (when the linker sees R_PLT_PC, it knows that it needs to resolve the relocation not to the target symbol, but to the PLT entry for that symbol). Altering RelExpr does not require a new Symbol to be created as the relocation Target isn't changed. However it does mean that the relocation code and other areas need to distinguish between R_PC and R_PLT_PC. There are trade-offs for each approach, for example if Thunks were to change the RelExpr and indirect via some Thunk target then we would have to handle R_THUNK_PC and R_THUNK_PLT_PC. Redirecting the relocation Targets means that calls to Thunks can be resolved like any other branch relocation.
>
> BTW, one change I would like to try once all thunk logic is implemented
> is to change the relocation structure to have an SectionBase instead of
> a symbol.
>
> This would avoid an indirection and remove the need for R_PLT_PC for
> example, as it would be just R_PC with the plt section.
>
> But I really want to wait for all the thunk logic is implemented. It
> seems much easier to change the relocation logic once all the uses are
> known than to change it and potentially discard the changes if it turns
> out they are insufficient.
>
> Cheers,
> Rafael

Interesting idea; a possible alternative would be to define a symbol
for each plt entry, this would have the same effect although may need
some logic to avoid propagating the symbols into the output. I guess
the difficulties will fall out when it is tried.

Peter


More information about the llvm-commits mailing list