| |||
Home > ARM Compiler Reference > Compiler-specific features > Pragmas |
Pragmas of the following form are recognized by the ARM compiler:
#pragma [no_]feature-name
Pragmas are listed in Table 3.1. The following sections describe these pragmas in more detail.
Table 3.1. Pragmas recognized by the ARM compilers
Pragma name | Default | Reference |
---|---|---|
arm section | Off | Pragmas controlling code generation |
check_printf_formats | Off | Pragmas controlling printf and scanf argument checking |
check_scanf_formats | Off | Pragmas controlling printf and scanf argument checking |
check_stack | On | Pragmas controlling code generation |
debug | On | Pragmas controlling debugging |
import | – | Pragmas controlling code generation |
Ospace | – | Pragmas controlling optimization |
Otime | – | Pragmas controlling optimization |
O | – | Pragmas controlling optimization |
softfp_linkage | Off | Pragmas controlling code generation |
The following pragmas control type checking of printf-like and scanf-like arguments:
check_printf_formats
This pragma marks printf-like functions for type checking against a literal format string, if it exists. If the format is not a literal string, no type checking is done. The format string must be the last fixed argument. For example:
#pragma check_printf_formats extern void myprintf(const char * format,...); //printf format #pragma no_check_printf_formats
check_scanf_formats
This pragma marks a function declared as a scanf-like function, so that the arguments are type checked against the literal format string. If the format is not a literal string, no type checking is done. The format string must be the last fixed argument. For example:
#pragma check_scanf_formats extern void myformat(const char * format,...); //scanf format #pragma no_check_scanf_formats
The following pragma controls aspects of debug table generation:
debug
This pragma turns debug table generation on or off.
If #pragma no_debug
is specified, no debug
table entries are generated for subsequent declarations and functions
until the next #pragma debug
.
The following pragmas control aspects of optimization:
Ospace
This pragma optimizes for space (uppercase O).
Otime
This pragma optimizes for time.
Onum
This pragma changes optimization level. The value
of
is 0, 1, or
2. See Defining optimization criteria for
more information on optimization levels.num
The following pragmas control how code is generated. Many other code generation options are available from the compiler command line:
check_stack
This
pragma reenables the generation of function entry code that checks for
stack limit violation if stack checking has been disabled with #pragma no_check_stack
and
the -apcs /swst
command-line option is used.
softfp_linkage
This pragma asserts that all function declarations
up to the next #pragma no_softfp_linkage
describe
functions that use software floating-point linkage. The __softfp
keyword
has the same effect and is preferred (see Function keywords). The pragma form can be useful when applied
to an entire interface specification (header file) without altering that
file.
import(symbol_name
)
This pragma generates an importing reference to
.
This is the same as the assembler directive:symbol_name
IMPORT symbol_name
The symbol name is placed in the symbol table of the image as an external symbol. It is otherwise unused. You must not define the symbol or make a reference to it.
You can use this pragma to select certain features of the C library, such as the heap implementation or real-time division. For an example of its use, see Avoiding the semihosting SWI.
arm section section_sort_list
This pragma specifies the code or data section name that used for subsequent functions or objects. This includes definitions of anonymous objects the compiler creates for initializations. The option has no effect on:
declarations
inline functions (and their local static variables)
template instantiations (and their local static variables)
elimination of unused variables and functions
the order in which definitions are written to the object file.
The full syntax for the pragma is :
#pragma arm section [sort_type
[[=]"name
"]] [,sort_type
="name
"]*
Where
is
the name to use for the section and name
is
one of:sort_type
code
rwdata
rodata
zidata
.
If
is
specified but sort_type
is
not, the section name for name
is reset
to the default value. Enter sort_type
#pragma arm section
on
its own to restore the names of all object sections to their defaults.
See Example 3.1.
Example 3.1. Section naming
int x1 = 5; // in .data (default) int y1[100]; // in .bss (default) int const z1[3] = {1,2,3}; // in .constdata (default) #pragma arm section rwdata = "foo", rodata = "bar" int x2 = 5; // in foo (data part of region) int y2[100]; // in .bss int const z2[3] = {1,2,3}; // in bar char *s2 = "abc"; // s2 in foo, "abc" in bar #pragma arm section rodata int x3 = 5; // in foo int y3[100]; // in .bss int const z3[3] = {1,2,3}; // in .constdata char *s3 = "abc"; // s3 in foo, "abc" in .constdata #pragma arm section code = "foo" int add1(int x) // in foo (code part of region) { return x+1; } #pragma arm section code
Use a scatter-loading description file with the linker to control placing a named section at a particular address in memory (see the ADS Linker and Utilities Guide).