Note Section
Sometimes a vendor or system engineer needs to mark an object file with special information that other programs will check for conformance, compatibility, and so forth. Sections of type SHT_NOTE and program header elements of type PT_NOTE can be used for this purpose.
The note information in sections and program header elements holds any number of entries, as shown in the following figure. For 64- and 32-bit objects, each entry is an array of 4-byte words in the format of the target processor. Labels are shown in Figure 7-6 to help explain note information organization, but they are not part of the specification.
Figure 7-5 Note Information
The elements of the structure are:
- namesz and name
The first namesz bytes in name contain a null-terminated character representation of the entry's owner or originator. There is no formal mechanism for avoiding name conflicts. By convention, vendors use their own name, such as "XYZ Computer Company," as the identifier. If no name is present, namesz contains 0. Padding is present, if necessary, to ensure 4-byte alignment for the descriptor. Such padding is not included in namesz.
- descsz and desc
The first descsz bytes in desc hold the note descriptor. If no descriptor is present, descsz contains 0. Padding is present, if necessary, to ensure 4-byte alignment for the next note entry. Such padding is not included in descsz.
- type
Provides the interpretation of the descriptor. Each originator controls its own types. Multiple interpretations of a single type value can exist. A program must recognize both the name and the type to understand a descriptor. Types currently must be nonnegative.
The note segment shown in the following figure holds two entries.
Figure 7-6 Example Note Segment
Note - The system reserves note information with no name (namesz == 0) and with a zero-length name (name[0] == '\0') but currently defines no types. All other names must have at least one non-null character.
Move Section
Typically, within ELF files, initialized data variables are maintained within the object file. If a data variable is very large and only contains a small number of initialized (nonzero) elements, the entire variable is still maintained in the object file.
Objects that contain large partially initialized data variables, such as FORTRAN COMMON blocks, can result in a significant disk space overhead. The SHT_SUNW_move section provides a mechanism of compressing these data variables. This compression reduces the disk size of the associated object.
The SHT_SUNW_move section contains multiple entries of the type ELF32_Move or Elf64_Move. These entries allow data variables to be defined as tentative items (.bss), thus occupying no space in the object file but contributing to the object's memory image at runtime. The move records establish how the memory image is initialized with data to construct the complete data variable.
ELF32_Move and Elf64_Move entries are defined as follows:
typedef struct {
Elf32_Lword m_value;
Elf32_Word m_info;
Elf32_Word m_poffset;
Elf32_Half m_repeat;
Elf32_Half m_stride;
} Elf32_Move;
#define ELF32_M_SYM(info) ((info)>>8)
#define ELF32_M_SIZE(info) ((unsigned char)(info))
#define ELF32_M_INFO(sym, size) (((sym)<<8)+(unsigned char)(size))
typedef struct {
Elf64_Lword m_value;
Elf64_Xword m_info;
Elf64_Xword m_poffset;
Elf64_Half m_repeat;
Elf64_Half m_stride;
} Elf64_Move;
#define ELF64_M_SYM(info) ((info)>>8)
#define ELF64_M_SIZE(info) ((unsigned char)(info))
#define ELF64_M_INFO(sym, size) (((sym)<<8)+(unsigned char)(size))
|
The elements of these structures are:
- m_value
The initialization value, which is the value that will be moved into the memory image.
- m_info
The symbol table index, with respect to which the initialization is applied, together with the size, in bytes, of the offset being initialized. The lower 8 bits of the member define the size, which can be 1, 2, 4 or 8. The upper bytes define the symbol index.
- m_poffset
The offset relative to the associated symbol to which the initialization is applied.
- m_repeat
A repetition count.
- m_stride
The stride count. This value indicates the number of units that should be skipped when performing a repetitive initialization. A unit is the size of an initialization object as defined by m_info. An m_stride value of 0 indicates that the initialization be performed contiguously for m_repeat units.
The following data definition would traditionally consume 0x8000 bytes within an object file:
typedef struct {
int one;
char two;
} Data
Data move[0x1000] = {
{0, 0}, {1, '1'}, {0, 0},
{0xf, 'F'}, {0xf, 'F'}, {0, 0},
{0xe, 'E'}, {0, 0}, {0xe, 'E'}
};
|
Using an SHT_SUNW_move section the data item can be moved to the .bss section and initialized with the associated move entries:
$ elfdump -s data | fgrep move
[17] 0x00020868 0x00008000 OBJT GLOB 0 .bss move
$ elfdump -m data
Move Section: .SUNW_move
offset ndx size repeat stride value with respect to
0x8 0x17 4 1 0 0x1 move
0xc 0x17 1 1 0 0x31 move
0x18 0x17 4 2 2 0xf move
0x1c 0x17 1 2 8 0x46 move
0x28 0x17 4 2 4 0xe move
0x2c 0x17 1 2 16 0x45 move |
Move sections supplied from relocatable objects are concatenated and output in the object being created by the link-editor. However, the following conditions cause the link-editor to process the move entries and expand their contents into a traditional data item:
The output file is a static executable.
The size of the move entries is greater than the size of the symbol into which the move data would be expanded.
Dynamic Linking
This section describes the object file information and system actions that create running programs. Most information here applies to all systems. Information specific to one processor resides in sections marked accordingly.
Executable and shared object files statically represent application programs. To execute such programs, the system uses the files to create dynamic program representations, or process images. A process image has segments that contain its text, data, stack, and so on. The major subsections of this section are:
"Program Header" describes object file structures that are directly involved in program execution. The primary data structure, a program header table, locates segment images in the file and contains other information needed to create the memory image of the program.
"Program Loading (Processor-Specific)" describes the information used to load a program into memory.
"Runtime Linker" describes the information used to specify and resolve symbolic references among the object files of the process image.