Non-Confidential | ![]() | ARM DUI0472J | ||
| ||||
Home > Compiler Command-line Options > --apcs=qualifier...qualifier |
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.
--apcs=
qualifier
...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
ARM recommends that you use --apcs
instead.
The /
prefix is optional for the first qualifier, but must be present to
separate subsequent qualifiers in the same --apcs
option. For example,
--apcs=/nointerwork/noropi/norwpi
is equivalent to
--apcs=nointerwork/noropi/norwpi
.
You can specify multiple qualifiers using either a single --apcs
option
or multiple --apcs
options. For example,
--apcs=/nointerwork/noropi/norwpi
is equivalent to
--apcs=/nointerwork
--apcs=noropi/norwpi
.
If you do not specify an --apcs
option, the compiler assumes
--apcs=/nointerwork/noropi/norwpi/nofpic
.
/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.
--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.
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.
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.
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
option. For example:--lower_ropi
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
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.