ARM Compiler toolchain v4.1 for µVision Compiler Reference
Home > Compiler Command-line Options > 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.

Show/hideSyntax

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

Show/hideDefault

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

Show/hideUsage

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

Show/hideRestrictions

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.

Show/hideSee also

Copyright © 2007-2008, 2011 ARM. All rights reserved.ARM DUI 0376C
Non-ConfidentialID061811
PDF file icon  PDF version
Home > Compiler Command-line Options > Command-line options > --apcs=qualifer...qualifier