3.1.1. 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 nameDefaultReference
arm sectionOffPragmas controlling code generation
check_printf_formatsOffPragmas controlling printf and scanf argument checking
check_scanf_formatsOffPragmas controlling printf and scanf argument checking
check_stackOnPragmas controlling code generation
debugOnPragmas controlling debugging
importPragmas controlling code generation
OspacePragmas controlling optimization
OtimePragmas controlling optimization
OnumPragmas controlling optimization
softfp_linkageOffPragmas controlling code generation

Pragmas controlling printf and scanf argument checking

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

Pragmas controlling debugging

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.

Pragmas controlling optimization

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 num is 0, 1, or 2. See Defining optimization criteria for more information on optimization levels.

Pragmas controlling code generation

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 symbol_name. This is the same as the assembler directive:


    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 name is the name to use for the section and sort_type is one of:

  • code

  • rwdata

  • rodata

  • zidata.

If sort_type is specified but name is not, the section name for sort_type is reset to the default value. Enter #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).

Copyright © 1999-2001 ARM Limited. All rights reserved.ARM DUI 0067D
Non-Confidential