Compiler Reference Guide

--apcs=qualifer...qualifier

ARM Compiler toolchain v5.02 for µVision Compiler Reference

Home > Compiler Command-line Options > --apcs=qualifer...qualifier

`--apcs=qualifer...qualifier`

This option controls interworking and position independence when generating code.

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.

Syntax

--apcs=qualifer...qualifier

where qualifier...qualifier denotes a list of qualifiers. There must be:

at least one qualifier present
no spaces separating individual qualifiers in the list.

Each instance of qualifier must be one of:

/interwork, /nointerwork: Generates code with or without ARM/Thumb interworking support. The default is /nointerwork, except for ARMv5T and later where the default is /interwork.
/ropi, /noropi: Enables or disables the generation of Read-Only Position-Independent (ROPI) code. The default is /noropi.
/[no]pic is an alias for /[no]ropi.
/rwpi, /norwpi: Enables or disables the generation of Read/Write Position-Independent (RWPI) code. The default is /norwpi.
/[no]pid is an alias for /[no]rwpi.
/fpic, /nofpic: Enables or disables the generation of read-only position-independent code where relative address references are independent of the location where your program is loaded.
/hardfp, /softfp: Requests hardware or software floating-point linkage. This enables the procedure call standard to be specified separately from the version of the floating-point hardware available through the --fpu option. It is still possible to specify the procedure call standard by using the --fpu option, but the use of --apcs is recommended.

Note

You can alternatively specify multiple qualifiers. For example, --apcs=/nointerwork/noropi/norwpi is equivalent to --apcs=/nointerwork --apcs=noropi/norwpi.

Note

The Evaluation and LabVIEW Evaluation variants only allow the following --apcs command line options: /nointerwork, /nointer, /interwork, /inter, /noropi, /norwpi, /nopid, /nofpic.

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 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:

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.

The /hardfp and /softfp qualifiers are mutually exclusive.

/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:

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.

The /hardfp and /softfp qualifiers are mutually exclusive.

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.

Compiler Reference Guide

--apcs=qualifer...qualifier

`--apcs=qualifer...qualifier`

Syntax

Note

Note

Default

Usage

Note

Note

Note

Restrictions

Note

See also

Products

Development Tools

Hardware & Collateral

Downloads

Support

Contact

Important information