[Bug c/94236] New: -mcmodel=large does not work on aarch64

[Bug c/94236] New: -mcmodel=large does not work on aarch64

[baratharon at caesar dot elte.hu]

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

            Bug ID: 94236
           Summary: -mcmodel=large does not work on aarch64
           Product: gcc
           Version: 9.2.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c
          Assignee: unassigned at gcc dot gnu.org
          Reporter: baratharon at caesar dot elte.hu
  Target Milestone: ---

Hello,

If I compile an object file with -mcmodel=large, then the compiler produces
short jumps to the function. I see R_AARCH64_CALL26 relocation in the object
file (via readelf), but I'd expect R_AARCH64_ABS64 or something equivalent like
R_AARCH64_MOVW_UABS_G0 (and their friends). The CALL26 is not the right
relocation in there.

For example, on x86_64, I get R_X86_64_64 relocation there, which is correct.
On armv7, I get R_ARM_MOVT_ABS and R_ARM_MOVW_ABS_NC, which is also correct.

See resources below.

TIA,
Aron



$ cat a.c
int func(void);
int main()
{
        return func();
}


$ aarch64-linux-gnu-gcc -static -fno-pie -fno-pic -mcmodel=large -c a.c

$ aarch64-linux-gnu-objdump -D a.o | grep func
   8:   94000000        bl      0 <func>

$ aarch64-linux-gnu-readelf -a a.o | grep func
000000000008  000b0000011b R_AARCH64_CALL26  0000000000000000 func + 0
    11: 0000000000000000     0 NOTYPE  GLOBAL DEFAULT  UND func

$ aarch64-linux-gnu-gcc -v
Using built-in specs.
COLLECT_GCC=aarch64-linux-gnu-gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/aarch64-linux-gnu/9.2.0/lto-wrapper
Target: aarch64-linux-gnu
Configured with: /build/aarch64-linux-gnu-gcc/src/gcc-9.2.0/configure
--prefix=/usr --program-prefix=aarch64-linux-gnu-
--with-local-prefix=/usr/aarch64-linux-gnu
--with-sysroot=/usr/aarch64-linux-gnu
--with-build-sysroot=/usr/aarch64-linux-gnu
--with-native-system-header-dir=/include --libdir=/usr/lib
--libexecdir=/usr/lib --target=aarch64-linux-gnu --host=x86_64-pc-linux-gnu
--build=x86_64-pc-linux-gnu --disable-nls --enable-languages=c,c++,fortran
--enable-shared --enable-threads=posix --with-system-zlib --with-isl
--enable-__cxa_atexit --disable-libunwind-exceptions --enable-clocale=gnu
--disable-libstdcxx-pch --disable-libssp --enable-gnu-unique-object
--enable-linker-build-id --enable-lto --enable-plugin
--enable-install-libiberty --with-linker-hash-style=gnu
--enable-gnu-indirect-function --disable-multilib --disable-werror
--enable-checking=release
Thread model: posix
gcc version 9.2.0 (GCC) 

$ uname -a
Linux ****** 4.18.14-arch1-1-ARCH #1 SMP PREEMPT Sat Oct 13 13:42:37 UTC 2018
x86_64 GNU/Linux

[Bug target/94236] -mcmodel=large does not work on aarch64

[pinskia at gcc dot gnu.org]

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

--- Comment #1 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
-mcmodel=large does not control long calls.

[Bug target/94236] -mcmodel=large does not work on aarch64

[pinskia at gcc dot gnu.org]

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

--- Comment #2 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
A patch for -mlong-calls was posted a long time ago but never made it in:
https://gcc.gnu.org/legacy-ml/gcc-patches/2014-10/msg02933.html

You should not need -mlong-calls really because the linker should insert stubs
to do the long calls in the end.
Why do you think you need full 64bit addressing for calls rather than the
stubs?

[Bug target/94236] -mcmodel=large does not work on aarch64

[baratharon at caesar dot elte.hu]

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

--- Comment #3 from Aron <baratharon at caesar dot elte.hu> ---
(In reply to Andrew Pinski from comment #1)
> -mcmodel=large does not control long calls.

Sadly, aarch64 lacks -mlong-calls which I use on armv7, therefore I thought
based on the specification -mcmodel=large would handle it. Also, on x86_64,
-mcmodel=large handles it. I'm confused.

[Bug target/94236] -mcmodel=large does not work on aarch64

[pinskia at gcc dot gnu.org]

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

--- Comment #4 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Do you have a source where you run into a relocation overflowing?
Or is there a specific reason why you need long calls here?

[Bug target/94236] -mcmodel=large does not work on aarch64

[baratharon at caesar dot elte.hu]

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

--- Comment #5 from Aron <baratharon at caesar dot elte.hu> ---
(In reply to Andrew Pinski from comment #4)
> Do you have a source where you run into a relocation overflowing?
> Or is there a specific reason why you need long calls here?

The current form of Threos OS requires such executables at a very early boot
stage. I wouldn't say it is impossible to change that stage, but I intended to
use the same method as on x86_64.

[Bug target/94236] -mcmodel=large does not work on aarch64

[pinskia at gcc dot gnu.org]

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

--- Comment #6 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Note for Threos OS, please don't reuse the same target triplet as elf or linux;
use your own triplet.  Also adding long calls is not hard and such.

[Bug target/94236] -mcmodel=large does not work on aarch64

[baratharon at caesar dot elte.hu]

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

--- Comment #7 from Aron <baratharon at caesar dot elte.hu> ---
(In reply to Andrew Pinski from comment #6)
> Note for Threos OS, please don't reuse the same target triplet as elf or
> linux; use your own triplet.  Also adding long calls is not hard and such.

As a simple start, I used the -ffreestanding -nostdlib -nostdinc combination,
but they did not made any difference on the output object file, so I removed
them in post #1. On x86_64 and armv7 we already have target (cross) gcc, but we
just started to work on aarch64. Either Linux target or Threos target, CALL26
would be also an issue. It seems, I have to mock with the target gcc first
before we can ran anything on the HW to include the long calls patch. Still, I
would be happy if the mainline gcc have the -mlong-calls for aarch64.

[Bug target/94236] -mcmodel=large does not work on aarch64

[rearnsha at gcc dot gnu.org]

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

--- Comment #8 from Richard Earnshaw <rearnsha at gcc dot gnu.org> ---
(In reply to Andrew Pinski from comment #6)
> Note for Threos OS, please don't reuse the same target triplet as elf or
> linux; use your own triplet.  Also adding long calls is not hard and such.

The correct solution is to implement long call support in the linker in
conformance with the ABI.

[Bug target/94236] -mcmodel=large does not work on aarch64

[wilco at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|---                         |INVALID
                 CC|                            |wilco at gcc dot gnu.org
             Status|UNCONFIRMED                 |RESOLVED

--- Comment #9 from Wilco <wilco at gcc dot gnu.org> ---
(In reply to Richard Earnshaw from comment #8)
> (In reply to Andrew Pinski from comment #6)
> > Note for Threos OS, please don't reuse the same target triplet as elf or
> > linux; use your own triplet.  Also adding long calls is not hard and such.
> 
> The correct solution is to implement long call support in the linker in
> conformance with the ABI.

And ld does this correctly, so I fail to see an actual issue here. -mlong-calls
is a terrible hack, so should be avoided unless it's to work around a broken
linker.