https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106270
--- Comment #5 from Wilco <wilco at gcc dot gnu.org> --- (In reply to Jose E. Marchesi from comment #3) > Wilco: The assessment in comment 1 was extracted from an internal discussion > on an issue that is still under investigation. We are certainly hitting a > cant-reach-the-linker-generated-veneer problem, but it is not fully clear to > us how since it is getting difficult to get proper reproducers. It is worth checking you're using a recent binutils since old ones had a bug in the veneer code (https://sourceware.org/bugzilla/show_bug.cgi?id=25665). You can hit offset limits easily if you use a linker script which places text sections very far apart. As the example shows, incorrect use of alignment directives can cause issues as well. Ideally the assembler should give a warning if there is a text section larger than 127 MB. > In any case, the idea of splitting of the text section by the compiler is > interesting, and a much better solution than -mlong-calls since it wouldn't > involve generate unnecessary indirect branches. > > But how would the back-end keep track on the size of the code it generates? > Using insn size attributes? Yes, GCC tracks branch ranges. CBZ and TBZ have a small range and are automatically handled if out of range. IIRC GCC doesn't yet extend Bcc, so if a single function is over 1MB, GCC won't be able to compile it.
