[Bug target/106270] New: [Aarch64] -mlong-calls should be provided on aarch64 for users with large applications

[Bug target/106270] New: [Aarch64] -mlong-calls should be provided on aarch64 for users with large applications

[qinzhao at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106270

            Bug ID: 106270
           Summary: [Aarch64] -mlong-calls should be provided on aarch64
                    for users with large applications
           Product: gcc
           Version: 13.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: target
          Assignee: unassigned at gcc dot gnu.org
          Reporter: qinzhao at gcc dot gnu.org
  Target Milestone: ---

Created attachment 53291
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53291&action=edit
tar ball for the small testing case

In aarch64 backend, aarch64_is_long_call_p always return FALSE by default, as a
result, direct calls (bl) are generated for all the calls. 

For smaller applications, generating direct calls by default for all the calls
will have good run-time performance. However, for larger applications, When the
size of the .text section exceed some limitation, linker will fail with the
following error:

 relocation truncated to fit: R_AARCH64_CALL26 against symbol 

This can be showed by the attached tar ball for a small testing case:

1. download the tar ball, and untar it;
2. cd aarch64_long_call
3. update the "GCC" in "build.sh", "assemble.sh" to your own gcc (gcc 8 and
above all have the same issue). 
4. sh do_all.sh

gcc -S bar.c foo.c
patching file bar.s
Hunk #1 succeeded at 21 (offset -2 lines).
gcc -c bar.s foo.s
ld: warning: cannot find entry symbol _start; defaulting to 0000000010000000
bar.o: In function `bar':
bar.c:(.text+0x10): relocation truncated to fit: R_AARCH64_CALL26 against
symbol `foo' defined in .text section in foo.o

[Bug target/106270] [Aarch64] -mlong-calls should be provided on aarch64 for users with large applications

[qinzhao at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106270

--- Comment #1 from qinzhao at gcc dot gnu.org ---
from Jose Marchesi:

====
We looked at this issue and these are our findings.

- When this problem happens: 

  When the linker (ld) fails to insert a veneer (that transforms the 
  immediate bl jumps generated by GCC into an indirect call) in range 
  with the original bl instruction. 

  This issue happens because it contains .text sections bigger than 
  ~128MiB or when the range between a bl instruction and the 
  beginning/or/end of the containing section exceeds ~128MiB. 

  Note that this also happens with linker-generated PLT sections when 
  linking shared objects, much like the veneers. 

- Proposed solutions: 

  We can think on two complementary solutions: 

  a) At the moment the aarch64 linker seems to only know how to insert a 
     veneer _after_ the section that contains the branch/call 
     instruction.  We could make the linker smarter so it knows how to 
     insert the veneer _before_ the sect on containing the branch/call 
     instruction. 

     This would make things better, but obviously would not work in all 
     cases. 

  b) So, in any case, we propose to add a new option to GCC (aarch64 
     specific) that will make GCC to generate indirect branch 
     instructions (blr) for non-PLT calls to symbols not having local 
     binding/scope: 

     -mlong-calls -> Make aarch64_is_long_call_p return true 
                  -> This makes GCC to generate blr instead of bl 
                     when compiling non-PIC and calls to symbol 
                     references with non-local binding. 
                  -> This will have an impact in performance, but 
                     this will _not_ impact inter-section calls nor 
                     to calls to local objects.

[Bug target/106270] [Aarch64] -mlong-calls should be provided on aarch64 for users with large applications

[wilco at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106270

Wilco <wilco at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |wilco at gcc dot gnu.org

--- Comment #2 from Wilco <wilco at gcc dot gnu.org> ---
GCC will crash well before reaching 128 MBytes of .text. So what is the real
underlying problem?

Note that GCC could split huge .text sections automatically to allow insertion
of linker veneers every 128MB. So -mlong-calls is simply an incorrect solution
for a problem that doesn't exist yet...

[Bug target/106270] [Aarch64] -mlong-calls should be provided on aarch64 for users with large applications

[jose.marchesi at oracle dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106270

--- Comment #3 from Jose E. Marchesi <jose.marchesi at oracle dot com> ---
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.

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?

[Bug target/106270] [Aarch64] -mlong-calls should be provided on aarch64 for users with large applications

[qing.zhao at oracle dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106270

--- Comment #4 from Qing Zhao <qing.zhao at oracle dot com> ---
> On Jul 12, 2022, at 1:02 PM, wilco at gcc dot gnu.org <gcc-bugzilla@gcc.gnu.org> wrote:
> 
> Note that GCC could split huge .text sections automatically to allow insertion
> of linker veneers every 128MB.

Does GCC do this by default? Any option is needed for this functionality?

[Bug target/106270] [Aarch64] -mlong-calls should be provided on aarch64 for users with large applications

[wilco at gcc dot gnu.org]

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.

[Bug target/106270] [Aarch64] -mlong-calls should be provided on aarch64 for users with large applications

[wilco at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106270

--- Comment #6 from Wilco <wilco at gcc dot gnu.org> ---
(In reply to Qing Zhao from comment #4)
> > On Jul 12, 2022, at 1:02 PM, wilco at gcc dot gnu.org <gcc-bugzilla@gcc.gnu.org> wrote:
> > 
> > Note that GCC could split huge .text sections automatically to allow insertion
> > of linker veneers every 128MB.
> 
> Does GCC do this by default? Any option is needed for this functionality?

No, currently it is not able to reach this limit, but once it can, it should be
done automatically.