"-mlong-calls " is not effective with clang

Clang Frontend
1

Looks like “-mlong-calls” is not processed from the clang driver and warns like

clang-15: warning: argument unused during compilation: ‘-mlong-calls’ [-Wunused-command-line-argument]

2

This is expected behaviour. The -mlong-calls option is target dependent and (currently) only has meaning on ARM, MIPS, and Hexagon. The addressing modes on the other architectures do not have a need for this flag.

3

@compnerd ,its not effective with --target=aarch64 ??and how we enforce the clang to emit register indirect call addressing for the function call for aarch64 ??
like Compiler Explorer

4

AFAIK, the AArch64 target does not support -mlong-calls. AIUI that is incumbent on the linker via branch islands/veneer synthesis to handle addressability concerns.

5

@compnerd ,thank you for your thoughts but aarch64 should support the same ,because arrch64 has the register indirect branch inst (br Rn) and compiler has to provide the option to emit the same .

is incumbent on the linker via branch islands/veneer synthesis
Make sense for the PC relative addressing mode when the ranges outside the limit .

6

I don’t see why the compiler has to do this. In fact, if you look at what GCC does, -mlong-calls will result in:

aarch64-unknown-linux-gnu-gcc: error: unrecognized command-line option '-mlong-calls'

Not generating the indirect call is generally a better option. The bl instruction gives you ±128 MiB addressability. For anything beyond that the linker is able to generate a veneer to perform the call. If the linker is able to arrange all the calls within the range this will give you a better final result. I am failing to see why it is imperative that the compiler perform this for labeled calls. If you just want to generate the indirect call, you can explicit spell it as an indirect call to force the compiler to generate that.

int g(int (*f)(void)) {
  return f();
}

will generate the following with clang:

g:
        br      x0
7

-mlong-calls is an old-fashioned compiler option. I think it was added before linkers knew range extension thunks (aka stubs, veneers, etc).

In 1992-10, GCC’s parisc port added -mlong-calls to change direct calls to indirect calls via a register.
The mips port added -mlong-calls in 1992-03.
The arm port added -mlong-calls in 1999-11.

binutils’ hppa port got range extension thunks before 1999-05.
binutils’ arm port added range extension thunks in 2008-05.

Modern architectures should not need -mlong-calls.

8

@MaskRay ,Thank you for information , but what about kernel modules that are built has relocatable image (-r) ?

9

Kernel modules generally need loading, which is done by some kind of linker and would be expected to implement veneers if it’s big enough to need them (128MB for a kernel is pretty big, my desktop Linux with all the bells and whistles looks like it comes in a ~70MB if I’m adding things up properly; about half of that is the nVidia driver).