section

This sophisticated and powerful pragma lets you arrange compiled object code into predefined sections and sections you define.

Note: Deprecated only when used without an associated __declspec(section) . To avoid C++ parsing ambiguities and other possible inadvertent errors, use __declspec(section) instead.

Syntax

#pragma section [ objecttype | permission ][iname][uname] 
  [data_mode=datamode][code_mode=codemode]

Parameter

objecttype

specifies where types of object data are stored. It may be one or more of these values:

code_type - executable object code
data_type - non-constant data of a size greater than the size specified in the small data threshold option in the EPPC Target settings panel
sdata_type - non-constant data of a size less than or equal to the size specified in the small data threshold option in the EPPC Target settings panel
const_type - constant data of a size greater than the size specified in the small const data threshold option in the EPPC Target settings panel
sconst_type - constant data of a size less than or equal to the size specified in the small const data threshold option in the EPPC Target settings panel
all_types - all code and data

Specify one or more of these object types without quotes separated by spaces.

The CodeWarrior C/C++ compiler generates some of its own data, such as exception and static initializer objects, which are not affected by #pragma section.

Note: To classify character strings, the CodeWarrior C/C++ compiler uses the setting of the Make Strings Read Only checkbox in the EPPC Processor settings panel. If the checkbox is checked, character strings are stored in the same section as data of type const_type. If the checkbox is clear, strings are stored in the same section as data for data_type.

permission

specifies access permission. It may be one or more of these values:

R - read only permission
W - write permission
X - execute permission

Specify one or more of these object types without quotes separated by spaces.

For more information on access permission, see "Section access permissions" on page 487.

iname

specifies the name of the section where the compiler stores initialized objects. Variables that are initialized at the time they are defined, functions, and character strings are examples of initialized objects.

The iname parameter may be of the form .abs.xxxxxxxx where xxxxxxxx is an 8-digit hexadecimal number specifying the address of the section.

uname

specifies the name of the section where the compiler stores uninitialized objects. This parameter is required for sections that have data objects. The uname parameter value may be a unique name or it may be the name of any previous iname or uname section. If the uname section is also an iname section then uninitialized data is stored in the same section as initialized objects.

The special uname COMM specifies that uninitialized data will be stored in the common section. The linker will put all common section data into the ".bss" section. When the Use Common Section checkbox is checked in the EPPC Processor panel, COMM is the default uname for the .data section. If the Use Common Section checkbox is clear, .bss is the default name of .data section.

The uname parameter value may be changed. For example, you may want most uninitialized data to go into the .bss section while specific variables be stored in the COMM section.

Storing Uninitialized Data in the COMM Section shows an example where specific uninitialized variables are stored in the COMM section.

Figure 1. Storing Uninitialized Data in the COMM Section

#pragma push // save the current state 
#pragma section ".data" "COMM" 
int red;
int sky;

#pragma pop // restore the previous state

Note: You may not use any of the object types, data modes, or code modes as the names of sections. Also, you may not use pre-defined section names in the PowerPC EABI for your own section names.

data_mode=datamode

specifies the compiler for the kind of addressing mode to be used for referring to data objects for a section.

The permissible addressing modes for datamode are:

near_abs - objects must be within the range -65,536 bytes to 65,536 bytes (16 bits on each side)
far_abs - objects must be within the first 32 bits of RAM
sda_rel - objects must be within a 32K range of the linker-defined small data base address
The sda_rel addressing mode may only be used with the ".sdata", ".sbss", ".sdata2", ".sbss2", ".PPC.EMB.sdata0", and ".PPC.EMB.sbss0" sections.

The default addressing mode for large data sections is far_abs. The default addressing mode for the predefined small data sections is sda_rel.

Specify one of these addressing modes without quotes.

code_mode=codemode

specifies the compiler for the kind of addressing mode to be used for referring to executable routines of a section.

The permissible addressing modes for codemode are:

pc_rel - routines must be within plus or minus 24 bits of where pc_rel is called from
near_abs - routines must be within the first 24 bits of memory address space
far_abs - routines must be within the first 32 bits of memory address space

The default addressing mode for executable code sections is pc_rel.

Specify one of these addressing modes without quotes.

Note: All sections have a data addressing mode (data_mode=datamode) and a code addressing mode (code_mode=codemode). Although the CodeWarrior C/C++ compiler for PowerPC embedded allows you to store executable code in data sections and data in executable code sections, this practice is not encouraged.

Remarks

CodeWarrior compilers generate their own data, such as exception and static initializer objects, which the #pragma section statement does not affect.

Section access permissions

When you define a section by using #pragma section, its default access permission is read only. Changing the definition of the section by associating an object type with it sets the appropriate access permissions for you. The compiler adjusts the access permission to allow the storage of newly-associated object types while continuing to allow objects of previously-allowed object types. For example, associating code_type with a section adds execute permission to that section. Associating data_type, sdata_type, or sconst_type with a section adds write permission to that section.

Occasionally you might create a section without associating it with an object type. You might do so to force an object into a section with the __declspec keyword. In this case, the compiler automatically updates the access permission for that section to allow the object to be stored in the section, then issue a warning. To avoid such a warning, make sure to give the section the proper access permissions before storing object code or data into it. As with associating an object type to a section, passing a specific permission adds to the permissions that a section already has.

Predefined sections and default sections

When an object type is associated with the predefined sections, the sections are set as default sections for that object type. After assigning an object type to a non-standard section, you may revert to the default section with one of the forms in "Forms for #pragma section" on page 488.

The compiler predefines the sections in Predefined sections .

Figure 2. Predefined sections

#pragma section code_type ".text" data_mode=far_abs code_mode=pc_rel 

#pragma section data_type ".data" ".bss" data_mode=far_abs 
code_mode=pc_rel

#pragma section const_type ".rodata" ".rodata" data_mode=far_abs 
code_mode=pc_rel

#pragma section sdata_type ".sdata" ".sbss" data_mode=sda_rel 
code_mode=pc_rel

#pragma section sconst_type ".sdata2" ".sbss2" data_mode=sda_rel 
code_mode=pc_rel

#pragma section ".PPC.EMB.sdata0" ".PPC.EMB.sbss0" data_mode=sda_rel 
code_mode=pc_rel

#pragma section RX ".init" ".init" data_mode=far_abs code_mode=pc_rel

Note: The .PPC.EMB.sdata0 and .PPC.EMB.sbss0 sections are predefined as an alternative to the sdata_type object type. The .init section is also predefined, but it is not a default section. The .init section is used for startup code.

Forms for #pragma section

#pragma section ".name1"

This form simply creates a section called .name1 if it does not already exist. With this form, the compiler does not store objects in the section without an appropriate, subsequent #pragma section statement or an item defined with the __declspec keyword. If only one section name is specified, it is considered the name of the initialized object section, iname. If the section is already declared, you may also optionally specify the uninitialized object section, uname. If you know that the section must have read and write permission, use #pragma section RW .name1 instead, especially if you use the __declspec keyword.

#pragma section objecttype ".name2"

With the addition of one or more object types, the compiler stores objects of the types specified in the section .name2. If .name2 does not exist, the compiler creates it with the appropriate access permissions. If only one section name is specified, it is considered the name of the initialized object section, iname. If the section is already declared, you may also optionally specify the uninitialized object section, uname.

#pragma section objecttype

When there is no iname parameter, the compiler resets the section for the object types specified to the default section. Resetting the section for an object type does not reset its addressing modes. You must reset them.

When declaring or setting sections, you also can add an uninitialized section to a section that did not have one originally by specifying a uname parameter. The corresponding uninitialized section of an initialized section may be the same.

Forcing individual objects into specificsections

You may store a specific object of an object type into a section other than the current section for that type without changing the current section. Use the __declspec keyword with the name of the target section and put it next to the extern declaration or static definition of the item you want to store in the section.

Using __declspec to Force Objects into Specific Sections shows examples.

Figure 3. Using __declspec to Force Objects into Specific Sections

__declspec(section ".data") extern int myVar; 
#pragma section "constants"
__declspec(section "constants") const int myConst = 0x12345678

Using #pragma section with #pragma push and #pragma pop

You can use this pragma with #pragma push and #pragma pop to ease complex or frequent changes to sections settings.

See Storing Uninitialized Data in the COMM Section for an example.

Note: The #pragma pop does not restore any changes to the access permissions of sections that exist before or after the corresponding #pragma push.