[Bug ld/25665] aarch64 veneers not inserted with large .text object between caller and target

[tnfchris at sourceware dot org]

https://sourceware.org/bugzilla/show_bug.cgi?id=25665

--- Comment #7 from Tamar Christina <tnfchris at sourceware dot org> ---
> If I implement the equivalent of -ffunction-sections, would this cause the 
> image expansion problem for A53 erratum you mentioned? 

I think `-ffunction-sections` alone won't help you on AArch64. It would
certainly make the problem very rare on AArch32 where then it's mostly large
single functions that would be an issue.

> Is it possible to keep track of the accumulated size of the input sections 
> and emit a shared veneer sub-section only when it is about to exceed 128k? 
> Then you only have to align to a 4K boundary every 128k.

It's tricky, the erratum workaround requires certain instructions to be at
certain PC values. So we can only know this when we have finished positioning
all sections.  But by then we can't change anything anymore.

This is the same reason why for instance if in the end we determine that the
erratum workaround isn't needed we still have to emit the large stub section.
We can't deallocate it anymore or decrease the size at that time. The only we
do is not write the workaround sequence in the stub.

I think a solution could be just to add a flag to control where the stubs are
placed. Default it to what it now is, and add one for putting them immediately
after the section like Arm does.

While this may cause the size increase I mentioned before, The erratum
workaround isn't needed on newer cores and when it is it's relatively rare.
Most binaries will have only a couple to a dozen. The stubs are only aligned
when it detects it may need the workaround so it's not always done.

In the cases where you'd need this it is unlikely to add much more to your
binary which is already quite big..

Would that work for you for a near term solution?

-- 
You are receiving this mail because:
You are on the CC list for the bug.