HP-UX Reference (11i v2 04/09) - 3 Library Functions A-M (vol 6)

e
elf_getdata(3E) elf_getdata(3E)
d_align This member holds the buffer’s required alignment, from the beginning of the section.
That is, d_off will be a multiple of this member’s value. For example, if this member’s
value is four, the beginning of the buffer will be four-byte aligned within the section.
Moreover, the entire section will be aligned to the maximum of its constituents, thus
ensuring appropriate alignment for a buffer within the section and within the file.
d_version This member holds the version number of the objects in the buffer. When the library ori-
ginally read the data from the object file, it used the working version to control the trans-
lation to memory objects.
Data Alignment
As mentioned above, data buffers within a section have explicit alignment constraints. Consequently,
adjacent buffers sometimes will not abut, causing ‘‘holes’’ within a section. Programs that create output
files have two ways of dealing with these holes.
First, the program can use elf_fill to tell the library how to set the intervening bytes. When the
library must generate gaps in the file, it uses the fill byte to initialize the data there. The library’s initial
fill value is zero, and elf_fill lets the application change that.
Second, the application can generate its own data buffers to occupy the gaps, filling the gaps with values
appropriate for the section being created. A program might even use different fill values for different sec-
tions. For example, it could set text sections’ bytes to no-operation instructions, while filling data section
holes with zero. Using this technique, the library finds no holes to fill, because the application eliminated
them.
Section and Memory Types
elf_getdata interprets sections’ data according to the section type, as noted in the section header
available through elf_getshdr (3E). The following table shows the section types and how the library
represents them with memory data types for the 32-bit file class. Other classes would have similar tables.
By implication, the memory data types control translation by elf_xlate (3E).
Section Type Elf_Type 32-Bit Type
SHT_DYNAMIC ELF_T_DYN Elf32_Dyn
SHT_DYNSYM ELF_T_SYM Elf32_Sym
SHT_HASH ELF_T_WORD Elf32_Word
SHT_NOBITS ELF_T_BYTE unsigned char
SHT_NOTE ELF_T_BYTE unsigned char
SHT_NULL none none
SHT_PROGBITS ELF_T_BYTE unsigned char
SHT_REL ELF_T_REL Elf32_Rel
SHT_RELA ELF_T_RELA Elf32_Rela
SHT_STRTAB ELF_T_BYTE unsigned char
SHT_SYMTAB ELF_T_SYM Elf32_Sym
other ELF_T_BYTE unsigned char
elf_rawdata creates a buffer with type ELF_T_BYTE.
As mentioned above, the program’s working version controls what structures the library creates for the
application. The library similarly interprets section types according to the versions. If a section type
‘‘belongs’’ to a version newer than the application’s working version, the library does not translate the sec-
tion data. Because the application cannot know the data format in this case, the library presents an
untranslated buffer of type
ELF_T_BYTE, just as it would for an unrecognized section type.
A section with a special type,
SHT_NOBITS, occupies no space in an object file, even when the section
header indicates a non-zero size. elf_getdata and elf_rawdata ‘‘work’’ on such a section, setting
the data structure to have a null buffer pointer and the type indicated above. Although no data is
present, the d_size value is set to the size from the section header. When a program is creating a new
section of type SHT_NOBITS, it should use elf_newdata to add data buffers to the section. These
‘‘empty’’ data buffers should have the d_size members set to the desired size and the d_buf members
set to null.
EXAMPLES
The following fragment obtains the string table that holds section names (ignoring error checking). See
elf_strptr (3E) for a variation of string table handling.
HP-UX 11i Version 2: September 2004 − 2 − Hewlett-Packard Company Section 3−−251