[PATCH] D31659: [LLD][ELF] Be more precise about Thumb state bit in ARM thunks

[Peter Smith via llvm-commits]

Thanks very much for the comment.

Just to check my understanding as I'm not totally sure what you mean
by creating synthetic sections earlier. I would like to contribute to
the solution as I'd very much like to get range thunks moving again.

My understanding is that the only sections requiring
LinkerScript::synchronize() are SHF_LINK_ORDER sections, as these are
reordered in OutputSection::finalize(). The .ARM.exidx sentinel
section is also added directly into OutputSection::Sections.

I agree that the sentinel section could be added much earlier, and
ideally link order sections would be reordered immediately after
section order for all other sections would be known. There is a size
optimization to compress identical .ARM.exidx table that is important
for C++ on embedded systems, and it is important that this is done
before Range Thunks as it can affect addresses. I'm happy to work on a
patch to move this earlier. RangeThunks can then insert into
InputSectionDescriptions without needing to resynch to the
OutputSections.

If the intention is to always alter the InputSectionDescriptions I'll
abandon the branch of D31656 - D31666.

Have I got this right or am I missing something more significant?

Peter


On 9 May 2017 at 20:54, Rafael Avila de Espindola
<rafael.espindola at gmail.com> wrote:
> Peter Smith <peter.smith at linaro.org> writes:
>
>> The second branch of reviews starts with D32799 this adds Thunks to
>> InputSectionDescriptions::Sections and synchronizes with
>> OutputSections::Sections at the end in order to be compatible with
>> LinkerScript::synchronize(). I've not posted the remainder of the
>> range extension Thunk patches on this approach, they will look very
>> much like D31656 - D31666 but with small implementation details
>> changed.
>>
>> What I think I really need to know right now is which approach to take
>> D31656 - D31666 or D32799, once I know that I can update or abandon
>> the reviews using the alternative approach. It would be great if you
>> could take a look at D32799 and let me know your opinion?
>
> I think the correct solution is to create synthetic sections earlier, so
> that LinkerScript::synchronize can be deleted. Any code changing
> OutputSections or the input sections in a particular OutputSection would
> then be changing the linker script commands *instead*.
>
> Cheers,
> Rafael