By specifying qualifiers to the --apcs command-line option, you can define the variant of the Procedure Call Standard for the ARM architecture (AAPCS) used by the compiler.

Default

If you do not specify an --apcs option, the compiler assumes --apcs=/nointerwork/noropi/norwpi/nofpic.

Usage

/interwork

/nointerwork

By default, code is generated:

• Without interworking support, that is /nointerwork, unless you specify a --cpu option that corresponds to architecture ARMv5T or later.

• With interworking support, that is /interwork, on ARMv5T and later. ARMv5T and later architectures provide direct support to interworking by using instructions such as BLX and load to program counter instructions.

/ropi

/noropi

If you select the /ropi qualifier to generate ROPI code, the compiler:

• Addresses read-only code and data PC-relative.

• Sets the Position Independent (PI) attribute on read-only output sections.

Note

--apcs=/ropi is not supported when compiling C++.

/rwpi

/norwpi

If you select the /rwpi qualifier to generate RWPI code, the compiler:

• addresses writable data using offsets from the static base register sb. This means that:

  • The base address of the RW data region can be fixed at runtime.

  • Data can have multiple instances.

  • Data can be, but does not have to be, position-independent.

• Sets the PI attribute on read/write output sections.

Note

Because the --lower_rwpi option is the default, code that is not RWPI is automatically transformed into equivalent code that is RWPI. This static initialization is done at runtime by the C++ constructor mechanism, even for C.

/fpic

/nofpic

If you select this option, the compiler:

• Accesses all static data using PC-relative addressing.

• Accesses all imported or exported read-write data using a Global Offset Table (GOT) entry created by the linker.

• Accesses all read-only data relative to the PC.

You must compile your code with /fpic if it uses shared objects. This is because relative addressing is only implemented when your code makes use of System V shared libraries.

You do not have to compile with /fpic if you are building either a static image or static library.

The use of /fpic is supported when compiling C++. In this case, virtual function tables and typeinfo are placed in read-write areas so that they can be accessed relative to the location of the PC.

Note

When building a System V or ARM Linux shared library, use --apcs /fpic together with --no_hide_all.

/hardfp

If you use /hardfp, the compiler generates code for hardware floating-point linkage. Hardware floating-point linkage uses the FPU registers to pass the arguments and return values.

/hardfp interacts with or overrides explicit or implicit use of --fpu as follows:

The /hardfp and /softfp qualifiers are mutually exclusive.

• If floating-point support is not permitted (for example, because --fpu=none is specified, or because of other means), /hardfp is ignored.

• If floating-point support is permitted, but without floating-point hardware (--fpu=softvfp), /hardfp gives an error.

• If floating-point hardware is available and the hardfp calling convention is used (--fpu=vfp...), /hardfp is ignored.

• If floating-point hardware is present and the softfp calling convention is used (--fpu=softvfp+vfp...), /hardfp gives an error.

/softfp

If you use /softfp, software floating-point linkage is used. Software floating-point linkage means that the parameters and return value for a function are passed using the ARM integer registers r0 to r3 and the stack.

/softfp interacts with or overrides explicit or implicit use of --fpu as follows:

The /hardfp and /softfp qualifiers are mutually exclusive.

• If floating-point support is not permitted (for example, because --fpu=none is specified, or because of other means), /softfp is ignored.

• If floating-point support is permitted, but without floating-point hardware (--fpu=softvfp), /softfp is ignored because the state is already /softfp.

• If floating-point hardware is present, /softfp forces the softfp (--fpu=softvfp+vfp...) calling convention.

Restrictions

There are restrictions when you compile code with /ropi, or /rwpi, or /fpic.

/ropi

The main restrictions when compiling with /ropi are:

• The use of --apcs=/ropi is not supported when compiling C++. You can compile only the C subset of C++ with /ropi.

• Some constructs that are legal C do not work when compiled for --apcs=/ropi. For example:

  extern const int ci; // ro
  const int *p2 = &ci; // this static initialization
                       // does not work with --apcs=/ropi
  

  To enable such static initializations to work, compile your code using the --lower_ropi option. For example:

  armcc --apcs=/ropi --lower_ropi

/rwpi

The main restrictions when compiling with /rwpi are:

• Some constructs that are legal C do not work when compiled for --apcs=/rwpi. For example:

  int i;               // rw
  int *p1 = &i;        // this static initialization
                       // does not work with --apcs=/rwpi
                       // --no_lower_rwpi
  

  To enable such static initializations to work, compile your code using the --lower_rwpi option. For example:

  armcc --apcs=/rwpi
  

  Note

  You do not have to specify --lower_rwpi, because this is the default.

/fpic

The main restrictions when compiling with /fpic are:

• By default, if you use --apcs=/fpic, the compiler exports only functions and data marked __declspec(dllexport).

• If you use --apcs=/fpic and --no_hide_all on the same command line, the compiler uses default ELF dynamic visibility for all extern variables and functions that do not use __declspec(dll*). The compiler disables auto-inlining for functions with default ELF visibility.