4.8 Program Sections

The following sections describe program-section attributes and program sections created by DEC C for OpenVMS Systems.

4.8.1 Attributes of Program Sections

As the DEC C compiler creates an object module, it groups data into contiguous program sections, or psects. The grouping depends on the attributes of the data and on whether the psects contain executable code or read/write variables.

The compiler also writes into each object module information about the program sections contained in it. The linker uses this information when it binds object modules into an executable image. As the linker allocates virtual memory for the image, it groups together program sections that have similar attributes.

Table 4-4 lists the attributes that can be applied to program sections.

Table 4-4 Program-Section Attributes

Attribute	Meaning
PIC or NOPIC	The program section or the data these attributes refers to does not depend on any specific virtual memory location (PIC), or else the program section depends on one or more virtual memory locations (NOPIC).[1]
CON or OVR	The program section is concatenated with other program sections with the same name (CON) or overlaid on the same memory locations (OVR).
REL or ABS	The data in the program section can be relocated within virtual memory (REL) or is not considered in the allocation of virtual memory (ABS).
GBL or LCL	The program section is part of one cluster, is referenced by the same program section name in different clusters (GBL), or is local to each cluster in which its name appears (LCL).
EXE or NOEXE	The program section contains executable code (EXE) or does not contain executable code (NOEXE).
WRT or NOWRT	The program section contains data that can be modified (WRT) or data that cannot be modified (NOWRT).
RD or NORD	These attributes are reserved for future use.
SHR or NOSHR	The program section can be shared in memory (SHR) or cannot be shared in memory (NOSHR).
USR or LIB	These attributes are reserved for future use.
VEC or NOVEC	The program section contains privileged change mode vectors (VEC) or does not contain those vectors (NOVEC).
COM or NOCOM	The program section is a conditionally defined psect associated with a conditionally defined symbol. This is the type of psect created when you declare an uninitialized definition with extern_model relaxed ref_ def.
[1] DEC C programs can be bound into PIC or NOPIC shareable images. NOPIC occurs if declarations such as the following are used: char x = &y;*. This statement relies on the address of variable y to determine the value of the pointer x.

4.8.2 Program Sections Created by DEC C

If necessary, DEC C creates the following program sections:

$CODE (VAX only)- Contains all executable code and constant data (including variables defined with the readonly modifier or const type qualifier).
$CODE$ (Alpha only)- Contains all executable code.
$READONLY$ (Alpha only)-Contains all constant data defined with the readonly modifier or const type qualifier.
$DATA (VAX only) or $DATA$ (Alpha only)- Contains all static variables, as well as global variables defined without the readonly modifier or const type qualifier. $DATA also contains character-string constants when /ASSUME=WRITABLE_STRING_LITERALS is specified.
$LITERAL$ (Alpha only)-Contains character-string constants when /ASSUME=NOWRITABLE_STRING_LITERALS is specified.
DEC C also creates additional program sections for variables declared with the globaldef keyword if the optional psect name in braces is specified, or for variables declared with the extern storage class, depending on the external model.

All program sections created by DEC C have the PIC, REL, RD, USR, and NOVEC attributes. On OpenVMS VAX systems, the $CODE psect is aligned on a byte boundary; all other psects generated by DEC C are aligned on longword boundaries. On OpenVMS Alpha systems, all psects generated by DEC C are aligned on octaword boundaries. Note that use of the _align storage-class modifier can cause a psect to be aligned on greater than a longword boundary on OpenVMS VAX systems. The $CHAR_STRING_CONSTANTS psect has the same attributes as the $DATA (VAX only) and $DATA$ (Alpha only) psects.

Tables 4-5, 4-6, 4-7, and 4-8 summarize the differences in psects created by different declarations:

Table 4-5, Table 4-6 (Alpha only), and Table 4-7 (VAX only) show different cases of variable definitions and assign to them a storage-class code number:
- Table 4-5 shows the effect of each #pragma extern_model preprocessor directive on the storage-class code number for external variable definitions that have an extern storage class.
- Table 4-6 shows the storage-class code number for variable definitions that do not have the extern storage class on OpenVMS Alpha systems.
- Table 4-7 shows the storage-class code number for variable definitions that do not have the extern storage class on OpenVMS VAX systems.
Table 4-8 shows the psect name and attributes associated with each storage-class code number from Tables 4-5, 4-6, and 4-7.

Table 4-5 External Models and Definitions

Storage- Class Code	External Object Definition	Interpretation
External Model: #pragma extern_ model common_block noshr
1	int name;	/* uninitialized definition * /
1	int name = 1;	/* initialized definition */
1	extern int name;	/* treated as an uninitialized definition */
2	const int name;	/* uninitialized definition */
2	const int name = 1;	/* initialized definition */
2	extern const int name;	/* treated as an uninitialized definition * /
External Model: #pragma extern_model common_block shr
3	int name;	/* uninitialized definition */
3	int name = 1;	/* initialized definition */
3	extern int name;	/* treated as an uninitialized definition */
4	const int name;	/* uninitialized definition */
4	const int name = 1;	/* initialized definition */
4	extern const int name;	/* treated as an uninitialized definition */
External Model: #pragma extern_model relaxed_refdef noshr
5	int name;	/* uninitialized definition */
1	int name = 1;	/* initialized definition */
6	const int name;	/* uninitialized definition */
2	const int name = 1;	/* initialized definition */
External Model: #pragma extern_model relaxed_refdef shr
7	int name;	/* uninitialized definition */
3	int name = 1;	/* initialized definition */
8	const int name;	/* uninitialized definition */
4	const int name = 1;	/* initialized definition */
External Model: #pragma extern_model strict_refdef
9 (Alpha only)	int symbol;	/* uninitialized definition */
10 (VAX only)	int symbol;	/* uninitialized definition */
10	int symbol = 1;	/* initialized definition */
11	const int symbol;	/* uninitialized definition */
11	const int symbol = 1;	/* initialized definition */
External Model: #pragma extern_model strict_refdef "name" noshr
12	int symbol;	/* uninitialized definition */
12	int symbol = 1;	/* initialized definition */
13	const int symbol;	/* uninitialized definition */
13	const int symbol = 1;	/* initialized definition */
External Model: #pragma extern_model strict_refdef "name" shr
14	int symbol;	/* uninitialized definition */
14	int symbol = 1;	/* initialized definition */
15	const int symbol;	/* uninitialized definition */
15	const int symbol = 1;	/* initialized definition */

Table 4-6 Combinations of Storage-Class Specifiers and Modifiers (Alpha only)

Storage- Class Code	Storage-Class Keyword Combination	/SHARE or /NOSHARE	Initialized or Not
9	static	Either	No
10	static	Either	Yes
11	static const[1]	Either	Either
9	globaldef	Either	No
10	globaldef	Either	Yes
11	globaldef const[1]	Either	Either
14	globaldef{"name"}	/SHARE	Either
12	globaldef{"name"}	/NOSHARE	Either
15	globaldef{"name"} const[1]	/SHARE	Either
13	globaldef{"name"} const[1]	/NOSHARE	Either
[1] Using readonly in place of const produces the same results.

Table 4-7 Combinations of Storage-Class Specifiers and Modifiers (VAX only)

Storage- Class Code	Storage-Class Keyword Combination	/SHARE or /NOSHARE
10	static	Either
11	static const[1]	Either
10	globaldef	Either
11	globaldef const[1]	Either
14	globaldef{"name"}	/SHARE
12	globaldef{"name"}	/NOSHARE
15	globaldef{"name"} const[1]	/SHARE
13	globaldef{"name"} const[1]	/NOSHARE
[1] Using readonly in place of const produces the same results.

Table 4-8 shows the psect name and psect attributes for the storage-class code numbers from Table 4-5, Table 4-6, and Table 4-7. Where name is used for the psect name in Table 4-8, the name of the psect is the same as name in the declarations or pragmas in Table 4-5, or the quoted brace-enclosed names in Tables 4-6 and 4-7.

Table 4-8 Combination Attributes

Storage- Class Code	Program Section Name	Program Attributes
1	name	OVR, GBL, NOSHR, NOEXE, WRT, NOCOM
2	name	OVR, GBL, NOSHR, NOEXE, NOWRT, NOCOM
3	name	OVR, GBL, SHR, NOEXE, WRT, NOCOM
4	name	OVR, GBL, SHR, NOEXE, NOWRT, NOCOM
5	name	OVR, GBL, NOSHR, NOEXE, WRT, COM
6	name	OVR, GBL, NOSHR, NOEXE, NOWRT, COM
7	name	OVR, GBL, SHR, NOEXE, WRT, COM
8	name	OVR, GBL, SHR, NOEXE, NOWRT, COM
9	$BSS$	CON, LCL, NOSHR, NOEXE, WRT, NOCOM
10	$DATA (VAX only)	CON, LCL, NOSHR, NOEXE, WRT, NOCOM
10	$DATA$ (Alpha only)	CON, LCL, NOSHR, NOEXE, WRT, NOCOM
11	$CODE (VAX only)	CON, LCL, SHR, EXE, NOWRT, NOCOM
11	$READONLY$ (Alpha only)	CON, LCL, SHR, NOEXE, NOWRT, NOCOM
12	"name"	CON, GBL, NOSHR, NOEXE, WRT, NOCOM
13	"name"	CON, GBL, NOSHR, NOEXE, NOWRT, NOCOM
14	"name"	CON, GBL, SHR, NOEXE, WRT, NOCOM
15	"name"	CON, GBL, SHR, NOEXE, NOWRT, NOCOM

The combined use of the readonly and noshare modifiers is ignored by the compiler in the following declarations:

readonly  noshare  static  int  x;
readonly  noshare  globaldef  int  x;

When it encounters a situation as shown in the previous example, the compiler ignores the noshare modifier and accepts readonly. The order of the storage-class specifier, the storage-class modifier, and the data-type keyword within a declaration is not significant.

The DEC C compiler does static (global) initialization of pointers by using the .ADDRESS directive. By using this mechanism, the compiler efficiently generates position-independent code. The linker makes image sections that contain such initialization nonshareable.

Previous Page | Next Page | Table of Contents | Index