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.
