ELF file format -
Write by Breadbox Email: Breadbox@muppetlabs.com
Translation: ALERT7
1. Ignore the score count. 2. For the above reasons, the page number is removed in this content directory, and the index is completely ignored. (Not like PostScript documents, txt text can be used to search) 3. The content of the page title and the footage of the article is already replaced at the beginning. 4. The layout of the article has also been corrected. 5. If necessary, different fonts have been ignored. Most places, this document can make you fully understand. However, small places, the original document uses a slope to indicate the character variable in the article. In that case, this article uses
If you have any other differences are my responsibility. Such a mistake, please, please, be: Breadbox@muppetlabs.com.
Brian raiter [Last Edited Fri Jul 23 1999]
_____________________________________________________
Executable and Linkable Format (ELF)
Portable Formats Specification, Version 1.1 Tool Interface Standards (TIS)
_____________________________________________________
=========================== ========================================================================================================================================================================================================================================= ======
Preface 1. Object file introduction ELF header sections string table (SYMBOL TABLE) Symbol table (Symbol Table) Relocation 2. Program loading and dynamic connection introduction Program header PROGRAM Loading Dynamic Linking 3. C library c library_______________________________________________________________________________________________________________________________________________________________________________________________________________
preface
_____________________________________________________
ELF: Performable connection format
The executable connection format is UNIX System Lab (USL) as an application binary interface (ABI) development and release. Tool Interface Standards Committee (TIS) Chooses the development of ELF standard as working in 32 Intel System Portable binary file format between different operating systems.
Assume that developers have defined a binary interface collection, and ELF standards use it to support streamlined software development. The number of different execution interfaces should be reduced. Therefore, you can reduce the reconstruction of the reconstruction.
About this document
This document is preparing for those who want to create target files or perform files on different operating systems. It is divided into three parts:
* Part 1, "Target Document Object Files" describes three main types of ELF target file format. * Part 2, "Program Reprint and Dynamic Connections" describe the information of the target file and the behavior of the system in creating a runtime program. * Part III, "C Library" lists all runners that contain symbols, standard ANSI C and LIBCs included in libsys, as well as global data symbols required by the libc run program.
Note: Reference X86 system has been changed to an Intel system.
_____________________________________________________
1. Object file
_____________________________________________________
========================= Preface ============================================================================================================================================================================= =
The first part describes the format of the IABI Object file, called EXECUTABLEAND LINKING FORMAT. There are three main types in the Object file.
* A Relocatable file holds code and appropriate data, uses other Object files to create an executable or a shared file. * An executable file holds a program for execution; this file indicates how Exec (ba_OS) is how to create a program process image. * A shared Object file saves code and appropriate data for links to the following two linkers. The first is to connect the editor [see LD (SD_CMD)], you can create other objects and share Object files with other heavy positionable and shared object files. The second is a dynamic linker, combined with an executable file and other shared object files to create a process image.
An Object file is created by the assembler and coupling, and the Object file you want to run directly on the process is stored in binary. Those programs that require abstract mechanisms are like the shell script, which is not accepted. After the introductory material, the first part mainly surrounds the format of the file and how to establish a program. The second part also describes several components of the Object file, focusing on the information necessary to execute the program.
file format
Object file participates in the program's connection (create a program) and execution of the program (running a program). The Object file format provides a convenient and effective way to view the content of the file in parallelism, in their activities, reflecting different needs. Example 1-1 shows an organization diagram of an Object file.
Figure 1-1: Object file format
LINKING Perspective Execution Perspective ============ ======================== Elf Header Elf Header Program Header Table (Optional) Program Header Table Segment 1 Segment 1 ... Segment 2 Section N ... section header Table section Header Table (optional)
An ELF header is in the beginning of the file, saves the road map (Road Map), describes the organization of the file. Sections saves the information of the Object file, from the perspective: including instructions, data, symbolic tables, relocation information, and more. Special Sections describes the first part of the future. The second part discusses the segment and the execution angle of the program.
If a program header (Program Header Table) exists, then it tells how to create a memory image of a process. Files used to establish a process image (executing a program) must have a program header; the relocationable file does not require this header. A section header contains information about describing the file sections. Each section has an entry in this table; each entry gives the name, size, and so on of the section. The file in the coupling process must have a section header; other Object files can not be this step header.
Note: Although the figure shows that the program header appears immediately after an ELF header, the section header appears to appear in the other section section, the fact is that the file is different. In addition, the segments and segments have no special order. Only the ELF header is a fixed location in the file.
Data indicates that the Object file format supports 8 bits, 32-bit different processors. However, it tries to work hard to run on a larger or smaller system. Therefore, Object files depict some control data need to be used with the machine-independent format, so that it uses the general method as much as possible to identify the Object file and describe their content. The remaining data in the Object file uses the coding method of the target processor, regardless of which the file is created on.
Figure 1-2: 32-bit data type ============================================================================================= ELF32_OFF 4 4 Unsigned File Offset Elf32_sword 4 4 Signed Large Integer Elf32_Word 4 4 Unsigned Large Integer Unsigned Char 1 1 Unsigned Small Integer
The data structure defined by all Object file formats is Natural Size, which adjusts pointers for related types. If necessary, the data structure is clearly included in the population field that makes sure 4 bytes aligned. To make the structure size of 4 times. Data is also appropriately aligned from the beginning of the file. For example, a structure containing an ELF32_ADDR will be aligned to the 4-byte boundary within the file.
Because of the transplantability, the ELF does not use the bit field.
========================== e h ==================================================================================================================================================================================== ====
Some Object files can grow, so the ELF header contains their current size. If the Object file format changes, the program may encounter or small or small to control the control structure. The program is also possible to ignore additional (extra) information. The information that is not unknown (MISSING) is explained by context, if the extension is defined, they will be specified.
Figure 1-3: Elf Header
#define Ei_NIDENT 16
typedef struct {unsigned char e_ident [EI_NIDENT]; Elf32_Half e_type; Elf32_Half e_machine; Elf32_Word e_version; Elf32_Addr e_entry; Elf32_Off e_phoff; Elf32_Off e_shoff; Elf32_Word e_flags; Elf32_Half e_ehsize; Elf32_Half e_phentsize; Elf32_Half e_phnum; Elf32_Half e_shentsize; Elf32_Half e_shnum; Elf32_Half e_shstrndx;} ELF32_EHDR; * E_IDENT
This initial field indicates that the file is an Object file, provides a machine-independent data, explaining the contents of the file. There is more detailed information in the ELF Identification part of the ELF below.
* E_TYPE
This member determines the type of the object.
Name Value Meaning ==== ===== ======= ET_NONE 0 No file type ET_REL 1 Relocatable file ET_EXEC 2 Executable file ET_DYN 3 Shared object file ET_CORE 4 Core file ET_LOPROC 0xff00 Processor-specific ET_HIPROC 0xffff Processor- Specific
Although the content of Core is not indicated, the type ET_CORE is reserved. The value is reserved for a special processor from ET_LOPROC to ET_HIPROC (including et_hiproc). If necessary, the other reserved variables will be used on the new Object file type.
* E_MACHINE
The member variable pointed out the architecture required to run the program.
Name Value Meaning ==== ===== ======= EM_NONE 0 No machine EM_M32 1 AT & T WE 32100 EM_SPARC 2 SPARC EM_386 3 Intel 80386 EM_68K 4 Motorola 68000 EM_88K 5 Motorola 88000 EM_860 7 Intel 80860 EM_MIPS 8 MIPS If RS3000 is required, the other reserved values will be used on new machine types. Special processor names use the machine name to distinguish them. For example, the member Flags that will be mentioned will use prefix EF_; on an EM_XYZ machine, Flag is called a widget, which is called EF_XYZ_WIDGET.
* e_version
This member determines the version of the Object file.
Name value meaning ==== ===== ======= EV_NONE 0 Invalid Version EV_CURRENT 1 CURRENT VERSION
Value 1 represents the original file format; create a new version to use> 1. EV_CURRENT value (1 above) If you need to point to the current version number.
* E_ENTRY
The member is the virtual address of the first transmission control of the system, where the startup process is started. If the file has not been associated with the entry point, the member remains 0.
* e_phoff
The member holds the offset (in byte count) in the program header (in byte count). If the file has no programmed head table, the member remains 0.
* E_SHOFF
The member maintains the offset (in byte count) in the section header (Section header Table). If the file does not have a section header, the member remains 0.
* E_FLAGS
The member holds a specific processor logo for related documents. The name of the FLAG comes from EF_
* E_EHSIZE
The member saves the ELF header size (in byte count).
* E_PHENTSIZE
The member saves the size of an inlet (in byte count) in the program header (in byte). All portions are the same size.
* e_phnum
The member saves the number of portions in the program header. Therefore, the flight of E_PHENTSIZE and E_PHNUM is the size of the table (in byte count). If there is no program header table, the E_PHNUM variable is 0.
* E_SHENTSIZE
The member saves the size of the section header (in byte count). A section header is an entry at the section header (Section header Table); all portions are the same size. * E_SHNUM
The member saves the number of entrances in the section header Table. Therefore, the product of E_SHENTSIZE and E_SHNUM is the size of the section header (in byte count). If the file does not have a section headset, the E_SHNUM value is 0.
* E_SHSTRNDX
The member saves the SECTION header index of the section's section name. If there is no section name character table in the file, the variable value is shn_undef. More detailed information Look at the "Sections" and string tables ("String Table").
ELF Identification (Identification)
The above mentioned, the ELF provides an Object file frame structure to support a variety of processors, a variety of data encoding methods, and a variety of machine types. In order to support this Object file family, the original byte specifies to explain how to explain the file, independent of the processor, independent of the content of the file.
The ELF header (that is, the Object file) is identical to the member E_IDENT.
Figure 1-4: E_ident [] Identification Indexes
Name Value Purpose ==== ===== ======= EI_MAG0 0 File identification EI_MAG1 1 File identification EI_MAG2 2 File identification EI_MAG3 3 File identification EI_CLASS 4 File class EI_DATA 5 Data encoding EI_VERSION 6 File version EI_PAD 7 Start Of Padding Bytes EI_NIDENT 16 SIZE OF E_IDENT []
By an index access byte, the following variables are defined.
* EI_MAG0 TO EI_MAG3
The first 4 characters of the file saves a magic number to determine if the file is the target file of ELF.
Name value position ================================================================================================================
* EI_CLASS
The next byte is e_ident [ei_class], used to determine the type or ability of the file.
Name value meaning ================ Elfclassnone 0 Invalid Class Elfclass32 1 32-bit Objects Elfclass64 2 64-bit objects file format is designed to be portable in different size machines, The size of the mainframe is not needed on the small machine. Type ELFCLASS32 supports virtual address space up to 4GB machine; use the basic type defined above.
Type ELFCLASS64 is a machine reserved for a 64-bit system. Its appearance indicates that the Object file may change, but the 64-bit format has not been defined. If necessary, other types will be defined, there will be different types and different sizes of data size.
* EI_DATA
Byte E_IDENT [EI_DATA] Specifies the encoding method of specific processor data in the Object file. The following encoding method is currently defined.
Name value meaning ==== ===== ======= Elfdatanone 0 invalid data encoding Elfdata2lsb 1 See Below Elfdata2msb 2 See Below
More information about the encoding appears below. Other values remain, will be assigned a new encoding method, of course, if necessary.
* Ei_Version
Byte E_IDENT [EI_Version] indicates the version number of the ELF header. Now this variable must be set to EV_CURRENT as an explanation of the E_VERSION above.
* Ei_pad
This variable identifies unused bytes starting in E_IDENT. Those bytes are reserved and set to 0; the program reads them from the Object file but should be ignored. If the bytes that are not currently used have new definitions, the EI_PAD variable will be changed.
A file's data coding indicates how to explain a basic Object file. In the above description, the type ELFCLAS32 file uses a target file that occupies 1, 2 and 4 bytes. The encoding method defined below is depicted with the following graph. The data appears in the upper left corner.
ElfData2lsb coding specifies 2 complement values. The minimum meaningful byte has the lowest address.
Figure 1-5: Data Encoding Elfdata2lsb
0 ------ 0x0102 | 01 | ------ 0 ------ 1 ------ 0x010204 | 02 | 01 | ------ - ----- 0 ------ 1 ------ 2 ------ 3 ------ 0x01020304 | 04 | 03 | 02 | 01 | ---- - ------ ------ ------
ElfData2lsb coding specifies 2 complement values. The biggest means occupy the lowest address.
Figure 1-6: Data Encoding Elfdata2MSB
0 ------ 0x0102 | 01 | ------ 0 ------ 1 ------ 0 0 010204 | 01 | 02 | ------ - ----- 0 ------ 1 ------ 2 ------ 3 ------ 0x01020304 | 01 | 02 | 03 | 04 | ---- - ------ ------ ---- Machine information
In order to determine the file, the 32-bit Intel architecture requires the following variables.
Figure 1-7: 32-bit intel architecture ideation, e_ident
Position value ======== ===== E_ident [ei_class] Elfclass32 e_ident [ei_data] Elfdata2lsb
The processor confirms the E_MACHINE member in the ELF header, which must be EM_386.
E_FLAGS members in the ELF header saves the bit tags related to the file. This tag is not defined on the 32-bit Intel system; so this member should be 0;
=========================== sxtions ====================== =====
The section header Table of an Object file allows us to locate all Sections. Section header table is an array of ELF32_SHDR structures (described below). A section header table index is the subscript of this array. E_SHOFF members of ELF Header Table give the offset of the section header (count from the beginning of the file). E_SHNUM tells us how many entrances contain in the section header table; E_SHENTSIZE gives the size of each entrance.
Some Section header table indexes are retained; those special indexes will have no corresponding sections with an Object file.
Figure 1-8: Special Section Indexes
Name value ===============================================================================================================2xff
* SHN_UNDEF
This value indicates that there is no definition, missing, irrelevant or other meaningful section. For example, the label "defined" relative to the section index number shn_undef is a label that is not defined.
Note: Although index 0 reserves the undefined value, the section header table contains an entry of index 0. Therefore, if the ELF header says 6 section portfolios in the section header table of a file, the value of E_SHNUM should be from 0 to 5. The content of the initial entrance will be specified in this section. * SHN_LORESERVE
This value specifies the minimum value of the reserved index range.
* SHN_LOPROC THROUGH SHN_HIPROC
This value includes a reservation range of a specific processor language.
* SHN_ABS
This variable is an absolute address relative to the corresponding reference. For example, the reference number of the Section number is an absolute address and is not affected by the relocation.
* SHN_COMMON
The Section's label is a public (COMMON), just like Fortran Common or the Unmissible C extension variable.
* Shn_hireserve
This value specifies the upper limit of the reserved index range. The index value of the system reserved is from Shn_LoreServe to Shn_HireServe; this variable does not involve the section header table. Therefore, the section header table contains the entry for the reserved index value. Sections contains all information in an Object file, in addition to the ELF header, Program header table, and section header table. In addition, the object file SECTIONS satisfies several days:
* Each section in the Object file has its own section header to describe it. The section headers may exist but section can not exist. * Each section occupies a continuous order in the file (but may be empty). * The sections in the file cannot be repeated. There is no byte in the file in this section and in another section. * Object files can have "non-active" space. Different headers and Sections may not override each byte in the Object file. The "non-active" data is not specified.
A section head has the following structure.
Figure 1-9: Section Header
typedef struct {Elf32_Word sh_name; Elf32_Word sh_type; Elf32_Word sh_flags; Elf32_Addr sh_addr; Elf32_Off sh_offset; Elf32_Word sh_size; Elf32_Word sh_link; Elf32_Word sh_info; Elf32_Word sh_addralign; Elf32_Word sh_entsize;} Elf32_Shdr;
* SH_NAME
The member specifies the name of this section. Its value is the index of the section header character table section. [Look at the following "String Table"], end with NULL empty characters.
* SH_TYPE
The member categorizes sections by content and meaning. Section's type and their description below.
* sh_flags
The SECTIONS support bit is used to describe multiple properties. FLAG definitions appear below.
* SH_ADDR
If the section will appear in the memory image space of the process, the member gives a position in the memory in memory. Otherwise, this variable is 0.
* SH_OFFSET
The member variable gives the section byte offset (counting from the file). SHT_NOBITS Type Section (discussed below) does not occupy space in the file, and its SH_OFFSET member is positioned in the concept of the file.
* SH_SIZE This member gives you the byte size of the section. Unless the type of this section is SHT_NOBITS, the section will occupy the SH_SIZE byte in the file. The SHT_NOBITS type section may be non-0 size, but does not account for file space. * SH_LINK
The member saves an index connection of a section header table, which relies on the type of section. One of the following describes these values.
* SH_INFO
The member saves additional information that relies on the type of section. One of the following plans these values.
* SH_ADDralign
Some Sections have an address alignment constraint. For example, if a section saves a double word, the system must determine if the entire section is aligned. Therefore, the value of SH_ADDR is used as the value of sh_addralign, so it is 0. Of course, only 0 and positive 2 is allowed. Values 0 and 1 mean that this section is not aligned.
* SH_ENTSIZE
Some Sections saves a table that fixed the size of the entrance, like the symbol table. For such a section, the member gives the byte size of each entrance. If the section does not save a table with a fixed size entry, the member is 0.
The section head member sh_type indicates the language of the section.
Figure 1-10: Section Types, SH_TYPE
Name Value ==== ===== SHT_NULL 0 SHT_PROGBITS 1 SHT_SYMTAB 2 SHT_STRTAB 3 SHT_RELA 4 SHT_HASH 5 SHT_DYNAMIC 6 SHT_NOTE 7 SHT_NOBITS 8 SHT_REL 9 SHT_SHLIB 10 SHT_DYNSYM 11 SHT_LOPROC 0x70000000 SHT_HIPROC 0x7fffffff SHT_LOUSER 0x80000000 SHT_HIUSER 0xffffffff
* SHT_NULL
This value indicates that the section header is invalid; it does not have a related section. The values of other members of this section are undefined.
* SHT_PROGBITS
This section saves some information defined by the program, which depends on the program itself.
* SHT_SYMTAB and SHT_DYNSYM
Those Sections saves a symbol table (Symbol Table). Under normal circumstances, an Object file has only one section, but in the future, this constraint may be relaxed. Typically, SHT_SYMTAB provides labels for connectors, of course, it may also be used dynamically. As a complete symbol table, it may contain some labels that are not required when dynamically connected. Therefore, an Object file may also contain a SHT_DYNSYM section, which saves the minimum label collection when a dynamic connection is saved. See the details of the Symbol Table in the following symbol table.
* SHT_STRTAB
This section saves a string table. An Object file can contain section of multiple string tables. Look at the details of the string "String Table".
* SHT_RELA This section saves a repositioning entry with explicit plus. Just like the Object file 32-bit ELF32_RELA type. An Object file may have multiple repositioned sections. The specific details are locked in `` Relocation ''.
* SHT_HASH
This label holds a latched hash table. All Participate Dynamic Connected Object must have a label hash table (Hash Table). Currently, an Object file may have only one hash table. Detailed detail looks at the second part of the hash table "hash table".
* SHT_DYNAMIC
This section saves the information of dynamic connection. Currently, an Object may have only one dynamic section, but this limit may be canceled in the future. Detailed detail see the dynamic section ("Dynamic Section") of the second part.
* SHT_NOTE
This section saves other information of some of the flag files. Detailed details Look at the "Note Section" of the second part.
* SHT_NOBITS
This type of section does not occupy space in the file, but similar to SHT_Progbits. Although the section does not contain bytes, the SH_OFFSET member contains the conceptual file offset.
* SHT_REL
This section saves an entry with a repositioning of a clear plus. Just like the Object file 32-bit type ELF32_REL type. An Object file may have multiple repositioned sections. The specific details are locked in `` Relocation ''.
* SHT_SHLIB
The section type is preserved but is not specified. The program containing this type of section does not match ABI.
* SHT_LOPROC THROUGH SHT_HIPROC
The value between this range is a specified processor.
* SHT_LOUSER
This variable is the smallest boundary of the application reserved index range.
* SHT_HIUSER
This variable is the maximum boundary of the index range reserved by the application. The section type of SHT_LOUSER and HIUSER may be used by the application, which is not contradictory in the schedule of the system or future system.
The variables of the other section type are reserved. As mentioned earlier, index 0 (shn_undef) The section header exists, even index tags is undefined section references. This entry saves the following information.
Figure 1-11: Section header Table Entry: Index 0
Name Value Note ==== ===== ==== sh_name 0 No name sh_type SHT_NULL Inactive sh_flags 0 No flags sh_addr 0 No address sh_offset 0 No file offset sh_size 0 No size sh_link SHN_UNDEF No link information sh_info 0 No auxiliary information SH_ADDralign 0 No Alignment SH_ENTSIZE 0 NO ENTRIES
The SH_FLAGS member of a section header Table saves a 1-bit tag to describe the properties of the section. The following is the defined value; other values are retained. Figure 1-12: Section Attribute Flags, Sh_Flags
Name value ==== ===== SHF_WRITE 0x1 shf_alloc 0x2 shf_execinstr 0x4 shf_maskproc 0xf0000000
If a marker bit in SH_FLAGS is set, the corresponding attribute of the section is also opened. Otherwise, this property is not applied. The unknown attribute is set to 0.
* SHF_WRITE
This section contains data that can be written during the process of execution. * SHF_ALLOC
This section occupies memory during the process execution. Some control sections does not exist in memory images of an Object file; for these sections, this property should be turned off.
* SHF_EXECINSTR
This section contains executable machine instructions.
* SHF_MASKPROC
All of the bits included in this mask are gently reserved for specific processing.
In the section header, the interpretation of two members SH_LINK and SH_INFO relies on the type of section.
Figure 1-13: SH_LINK AND SH_INFO Interpretation
SH_TYPE SH_LINK SH_INFO ======= ============== SHT_Dynamic the section header index of 0 the string Table Used by Entries in the section. sht_hash the section header index of 0 The Symbol table to which the hash table applies. SHT_REL, The section header index of The section header index of SHT_RELA the associated symbol table. the section to which the relocation applies. SHT_SYMTAB, The section header index of One greater than the symbol SHT_DYNSYM the associated string Table. INDEX of the last local symbol (binding stb_local). Other shn_undef 0
Special Sections Special SECTIONS
Different Sections saves program and control information. The section in the list below is used by the system, indicating type and properties. Figure 1-14: Special Sections
Name Type Attributes ==== ==== ========== .bss SHT_NOBITS SHF_ALLOC SHF_WRITE .comment SHT_PROGBITS none .data SHT_PROGBITS SHF_ALLOC SHF_WRITE .data1 SHT_PROGBITS SHF_ALLOC SHF_WRITE .debug SHT_PROGBITS none .dynamic SHT_DYNAMIC see below .dynstr SHT_STRTAB SHF_ALLOC .dynsym SHT_DYNSYM SHF_ALLOC .fini SHT_PROGBITS SHF_ALLOC SHF_EXECINSTR .got SHT_PROGBITS see below .hash SHT_HASH SHF_ALLOC .init SHT_PROGBITS SHF_ALLOC SHF_EXECINSTR .interp SHT_PROGBITS see below .line SHT_PROGBITS none .note SHT_NOTE none .plt SHT_PROGBITS see below. rel
* .bss
The SECTIOPN holds uninitialized data that exists in the program memory image. By definition, when the program starts, the system initializes those data 0. This section does not account for file space, just as its section type SHT_NOBITS indication. * .Comment
This section saves version control information.
* .data and .data1 These Sections saves the initialized data, and those data exist in the program memory image.
* .debug
This section saves information for debugging as label. This content is not specified.
* .dynamic
This section saves the information of dynamic connection. The properties of this section will include a SHF_alloc bit. Does SHF_WRITE are related to the processor. The second part has more detailed information.
* .dynStr
This section saves the string required when dynamically connected, in general, the name string associates the entrance to the symbol table. The second part has more detailed information.
* .dynsym
This section saves a dynamic symbol table, such as a description of Symbol Table. The second part has more detailed information. * .Fini This section saves the executable instruction that constitutes the termination code of the process. Therefore, when a program is exit, the system schedules the code in this section.
* .got
This section saves the global offset table. See "Special Offset Table" for the first part to get more information.
* .hash
This section saves a labet of a label. Look at the second part of "Hash Table" to get more information.
* .init
This section saves an executable instruction that constitutes the initialization code of the process. Therefore, when a program starts running, the system schedules the code in this section before the main function is called before the MAIN function is called.
* .interp
This section saves the program's interpretation path. If there is a loaded segment in this section, the SHF_alloc bit of the properties of this section will be set; otherwise, the bit will not be set. See the second part to get more information.
* .line
This section contains the number of row information of the character, which describes the relationship between the source program and the machine code. The section content is not clear.
* .note
This section saves some information, using the format mentioned in the "Note Section".
* .plt
This section saves the Procedure Linkage Table. Look at the first part of `` Special Sections '' and the second part of "Procedure Linkage Table".
* .rel
These sections saves the information that focuses on, look at the following `` Relocation '' description. If the file contains a loadable segment, and this segment is relocated, then the properties of the section will set the SHF_alloc bit; otherwise the bit is turned off. Follow the conventions,
* .rodata and.rodata1
These sections saves read-only data to construct unwritable segments in the process image. See the second part of `` program header '' get more information.
* .shstab
This section saves the section name.
* .sturtab
This section saves a string, typically, describes the character string of the name and the entry of a label. If the file has a loadable segment, and this segment includes a symbol string table, then the SHF_alloc property of the section will be set; otherwise it is not set.
* .symtab
This section saves a symbolic table, as described in this section `` Symbol Table ''. If the file has a loadable segment, and this section contains a symbol table, then the section's SHF_alloc property will be set; otherwise it is not set.
* .text
This section saves the program's `` text '' or is an executable instruction.
The prefix is a point (.) The section name is the system reserved, although the application can use those Section names. Applications can use non-prefixed names to avoid and systematically conflict. The Object file format allows a defined section portion that does not appear in the list. An Object file can have multiple sections of the same name. The formation of the section name retained for the processor system is an abbreviation for replacement into a system name. The name should be taken from the system name, and E_MACHINE is used. For example, .foo.psect is the name defined on the FOO system.
The existing extension is a history left.
Pre-existing extensions ================================ .sdata .tdesc .sbss .lit4 .lit8 .reginfo .gptab .liblist .conflict
=================== String Table string table ==========================
String Table Sections saves a series of characters terminated by NULL, usually we are called strings. The Object file uses these strings to draw symbols and section names. A reference for a string is an index of a String Table Section. The first byte, that is, index 0, is defined to save a NULL character. Similarly, the last byte of a String Table saves a null character, all strings are terminated with null. The string of index 0 is no name or NULL, and its explanation relies on the context. An empty String Table section is allowed; its SH_SIZE of its Section Header will be 0. For empty String Table, non-zero index is useless.
A SH_NAME member of a SETTION header saves an index corresponding to the SETIn header table (as specifically referred to as the E_SHSTRNDX member of the ELF header. The following table lists a string table with 25 bytes (these characters Strings and different indexes are related to:
Index 0 1 2 3 4 5 6 7 8 9 ===== == == == == == == == == == == 0/0 n A m e. / 0 V A R 10 I a b L E / 0 A B L E 20/0/0 x x / 0
Figure 1-15: String Table Indexes
Index string ===================================================================== byte. A string may be referenced more than once; the case of reference substrings may exist; a string may also be referenced; not the referenced string is also allowed.
==================== =============================
An Object file symbol table holds information that the program needs to be defined and referenced when positioning and relocation. A symbol table index is a corresponding subscript. 0 The entry specifically refers to the first entrance to the table, just like an undefined symbol index. The content of the initial entrance is specified in the subsequent portion of the section.
Name value ==== ===== STN_UNDEF 0
A symbol table entrance has the following format:
Figure 1-16: Symbol Table Entry
TYPEDEF STRUCT {ELF32_WORD ST_NAME; ELF32_ADDR ST_VALUE; ELF32_WORD ST_SIZE; UNSIGNED CHAR ST_INFO; UNSIGNED CHAR ST_ITHER; ELF32_HALF ST_SHNDX;} ELF32_SYM;
* ST_NAME
The member saves the index of the symbol string table entry to the Object file (the expression character of the symbol name). If the value is not 0, it represents a string table index that gives a symbolic name. Otherwise, the symbol is free.
Note: The symbolic table of the External C symbol and Object file has the same name.
* ST_VALUE
The member gives the corresponding symbol value. It may be an absolute or address, etc. (depending on the context); details are as follows.
* ST_SIZE
Many symbols and sizes are related. For example, a size of a data object is the number of bytes included in this object. This member is 0 if the size of the symbol is unknown or without size.
* ST_INFO
Members pointed out the type of symbols and the corresponding properties. The corresponding list is as follows. The following code illustrates how to operate this value.
#define ELF32_ST_BIND (i) ((i) >> 4) #define ELF32_ST_TYPE ELF32_ST_INFO (B, T) (((b) << 4) ((t) & 0xF) )
* ST_OTHER
The member is currently 0, there is no meaning.
* ST_SHNDX
Each of the symbol tables is defined as associated with some section; the member saves the relevant section header index. As described in Figures 1-8 {*} and related text, some section indexes pointed out a special meaning. The attribute of a symbol determines the linkable performance and behavior.
Figure 1-17: Symbol Binding, ELF32_ST_BIND
Name value ==== ===== STB_LOCAL 0 STB_GLOBAL 1 STB_WEAK 2 STB_LOPROC 13 STB_HIPROC 15
* STB_LOCAL
Local symbols other than the Object files therebetween are not visible. Local symbols with the same name in different files do not hinder each other.
* STB_GLOBAL
The global symbol is visible to all Object target files. The definition of global symbols in a file can meet the reference to the global symbol of the global symbol in another file.
* STB_WEAK
Weak symbols are similar to global symbols, but their definition is relatively low.
* STB_LOPROC THROUGH STB_HIPROC
The values in the range therebetween are retained by the corresponding processor semantics.
The difference between global symbols and weak symbols is mainly in two aspects.
* When the linker is linked to several heavy positionable target files, it does not allow the same name of the STB_GLOBAL symbol. On the other hand, if the definition of a global symbol exists, the weak symbol name with the same name will not cause an error. The linker will recognize the definition of global symbols and ignore the definition of weak symbols. Similarly, if there is a normal symbol (for example, a ST_SHNDX domain containing shn_common), a weak symbol of the same name will not cause an error. The linker also recognizes the definition of ordinary symbols and ignores the weak symbols.
* When the linker searches the archive, it selects an archive member that contains undefined global symbols. The member is defined or a global or a weak symbol. The linker does not select an archive member to solve an undefined weak symbol. Undefined weak symbols have 0 values.
In each symbol table, all symbols with STB_LOCAL constraints are preferred over the weak symbols and global symbols. As described in "Sections" above, the member in the SH_INFO header of a symbol table holds the symbol table index of the first non-local symbol.
The type of symbol provides a universal classification for the relevant entrance.
Figure 1-18: Symbol Types, ELF32_ST_TYPE
Name value =====================================================================003
* STT_NOTYPE
The type of the symbol is not specified.
* STT_OBJECT
This symbol is related to a data object, such as a variable, an array, and the like.
* STT_FUNC
This symbol is related to a function or other executable code.
* STT_SECTION
This symbol is related to a section. This type of symbol table inlet is mainly for relocation, and the general has STB_LOCAL constraints.
* STT_FILE
According to convention, the symbol gives the source file name associated with the target file. A file symbol with STB_LOCAL constraints, its section index is shn_abs, and it takes precedence over the other STB_LOCAL symbol currently on the file.
* STT_LOPROC THROUGH STT_HIPROC This range is preserved for the processor semantic.
The function symbols in the shared file (with the stt_func type) have special significance. When other target files reference a function from a shared file, the linker is automatically created a link table for reference symbols. In addition to STT_FUNC, the shared target symbol will not be automatically referenced by link tables.
If a symbol involves a section's specific positioning, its section index member ST_SHNDX will retain an index of the section header. When the section is constantly moving during the relocation process, the value of the symbol varies accordingly, and the reference to the symbol points to the same positioning in the program. Some special section indexes have other semantics.
* SHN_ABS
This symbol has an absolute value that does not change as heavier.
* SHN_COMMON
This symbol identifies a normal block that is not assigned. The value of the symbol gives the corresponding system parameters, just like a section of the SH_ADDralign member. That is, the linker will assign an address to the symbol, the value of the address is the multiple of ST_VALUE. The size of this symbol points out the number of bytes required. * SHN_UNDEF
The section table index indicates that the symbol is undefined. When the link is assembled with another file that defines the symbol, the reference will be linked to the current actual definition.
As mentioned above, the 0 index (STN_UNDEF) of the symbol table is retained, which contains the following:
Figure 1-19: Symbol Table Entry: Index 0
Name value note ==== ===== === ST_NAME 0 NO Name ST_VALUE 0 ZERO VALUE ST_SIZE 0 NO SIZE ST_INFO 0 NO TYPE, LOCAL BINDING ST_OTHER 0 ST_SHNDX SHN_UNDEF NO Section
Symbol Values (Symbol)
Symbol Table Entrance has some different explanations for ST_Value members for different target files.
* In a recurring file, ST_VALUE saves the force alignment value of the section index for the SHN_COMMON symbol.
* In a recreateable file, ST_VALUE saves a symbol's section offset. That is, ST_VALUE is the offset of the step out of the section defined from ST_SHNDX.
* ST_VALUE saves a virtual address in executable and shared target files. In order to make these file symbols for dynamic linkers more efficient, the section offset on the file level allows the virtual address located on the memory level (the section number independent).
Although the symbol table value has similar meaning to different target files, the corresponding program is also effective access to data.
====================== ingocation ======================== === Relocation is the process of connection symbol reference and symbol definition. For example, when a program calls a function, the relevant call must transmit the control to the correct target address when executed. In other words, the relocation file should contain information about how to modify their section content, allowing executables or shared target files to save the correct information for program images of a process. The reacting entry is such a data.
Figure 1-20: Relocation Entries
TYPEDEF STRUCT {ELF32_ADDR R_OFFSET; ELF32_WORD R_INFO; ELF32_REL;
TYPEDEF STRUCT {ELF32_ADDR R_OFFSET; ELF32_WORD R_INFO; ELF32_SWORD R_ADDEND; ELF32_RELA;
* r_offset
This member gives the address of the application relocation behavior. For a relocation file, this value is from the section start to the byte offset of the storage unit affected by the relocation. For an executable or a shared goal, this value is a virtual address of the storage unit affected by the relocation.
* r_info
The member gives a type of symbol table index and relocation applications with a significant focusing factor. For example, a relocation entry of a call instruction should include a symbol index that is called a function. If the index is STN_UNDEF (undefined symbol index), the relocation will use 0 as the value of the symbol. The relocation type is related to the processor. When the body (text) is referenced to a relocation type or a symbolic table index, it indicates the corresponding application ELF32_R_TYPE or ELF32_R_SYM members of the R_INFO member of the entrance.
#define ELF32_R_SYM (i) ((i) >> 8) #define ELF32_R_TYPE (I) ((unsigned char) (i)) #define ELF32_R_INFO (S, T) ((S) << 8 (unsigned char) ( t)
* R_ADDEND
This member specifies a constant plus (for calculating the value to be stored in the redifunction domain).
As mentioned above, only the ELF32_RELA entry contains a clear plus. The entry of the ELF32_REL type stores an implicit plus in an address that can be modified. Depending on the processor structure, a form or other form may be necessary or more convenient. Thus, the application of a particular machine should use a row-like form or to another form of context.
A relocation section is associated with two other section: a symbolic table and a modified section. The member SH_INFO and SH_LINK of the section header (described in the "section" section above) indicates this relationship. Members r_offset in the reset entrance have little differences for different target files.
* In a recreateable file, r_offset represents an section offset. That is, the relocation section describes how to modify other sections in the file; the relocation offset refers to the memory unit in the second section. * In executable and shared target files, R_OFFSET represents a virtual address. In order to make the relocation inlet of these files more useful (for dynamic linkers), the section offset should be allowed to be located in a virtual address (in memory).
Although the explanation of R_Offset is different for different target files in order to allow relevant procedures, the meaning of the relocation type is the same.
Relocation Types (repositioning type)
The relocation entry describes how to change the following instructions and data domains (the number of bits is at the angle of the table).
Figure 1-21: Relocatable Fields
------------------------ | Word32 | 31 ----------------- ---------- 0
* Word32
Specifies a 32-bit domain that occupies 4 bytes in any byte alignment. These values use the same byte order as the 32-bit Intel system.
3 ------ 2 ------ 1 ------ 0 ------ 0x01020304 | 01 | 02 | 03 | 04 | 31 ------ --- --- ------ ---- 0
The following calculation assumes that a recapacity positioning is being converted into an executable or shared target file. Conceptually, the linker combines one or more reconfigurable files to constitute an output. It first decides how to merge, locate input files, and then update the symbol value, and finalize. The relocation process is similar and has the same result for the executable files and shared target files. The following description uses the following convention symbols.
* A
Indicates the plus of the domain value for calculating the relocated domain.
* B
Indicates the base address when a shared target is loaded into memory during execution. Under normal circumstances, a shared Object file is 0, but an executable address is different from the shared object file.
* G
Indicates the offset in the overall entry symbol resides in the global offset table during the execution process. See "Global Offset Table" in the second section get more information.
* Got
Indicates the address of the global offset table. See "Global Offset Table" in the second section get more information.
* L * L
Represents a process link table inlet (section offset or address). A process linked table entry relocation a function call to the correct destination unit. The linker creates an initial link table, and the dynamic linker modifies the entry in the execution. See "Procedure Linkage Table" for more information on the "Procedure Linkage Table" in the second section.
* P
Indicates the position of the storage unit (using r_offset) by means (Section offset or address).
* S
Indicates the symbol value of the index resident in the reset entrance.
The R_OFFset value of a relocation entry specifies offset or virtual address of the first byte of the affected memory cell. The reacting type specifies which bit (bit) will change, and how to calculate their values. In the SYSTEM V system, just use the ELF32_REL relocation entry, and will retain the plus in the domain to be relocated. In all cases, the plus and calculation results use the same byte order. Figure 1-22 (Table 1-22): Relocation Types (reposition type)
Name Value Field Calculation ==== ========== ======================================================================================================================================================== G A - P R_386_PLT32 4 word32 L A - P R_386_COPY 5 none none R_386_GLOB_DAT 6 word32 S R_386_JMP_SLOT 7 word32 S R_386_RELATIVE 8 word32 B A R_386_GOTOFF 9 word32 S A - GOT R_386_GOTPC 10 word32 GOT A - P
Some relocation types are different from simple calculations.
* R_386_got32
This relocation type calculates the interval between the global offset table inlet to the symbol. This additionally notifies the Link Editor to establish a global offset table.
* R_386_plt32
This recipient type calculation symbol process link table entry address, and additionally notifies the linker to establish a process linked table.
* R_386_copy
The linker creates this relocation type for dynamic links. Its offset member involves a location in a canable section. Symbol table Index Specifies a symbol that may exist in the current Object File or in a shared object. During the execution, the dynamic linker copies the data related to the Shared Object symbol to the location specified by the offset.
* R_386_glob_dat
This type of relocation is used to set the address of a global offset table entry to the specified symbol. This particular relocation type allows you to determine the consistency between symbols and global offset table portals.
* R_386_JMP_slot {*}
The linker creates this relocation type for dynamic links. Its offset member gives a position of a process link table entry. Dynamic Links Modify the process link table inlet to pass control to a particular symbol address. [Refer to "Procedure Linkage Table" in the second part]]
* R_386_RELATIVE
The linker creates this relocation type for dynamic links. Its offset member gives the location in a shared object that contains the associated address value. Dynamic linker calculates the corresponding virtual address (adding the shared object loading address and relative address). This type of relocation entry must be specified as 0 for the symbol table index.
* R_386_gotoff
This relocation type calculates the difference between the symbol value and the global offset table address. Also notify the linker to establish a global offset table (GOT).
* R_386_gotpc
This reset type is similar to R_386_PC32, which is different from it uses a global offset table in the calculation. The symbols referenced in this relocation are typically _Global_offset_table_, which notifies the linker to establish a global offset table (GOT). _____________________________________________________
2. Program Loading and Dynamic Linking Programs Mounting and Dynamic Links _______________________________________________________________________________________________________________________________________________________________________________________________________________________
======================== ============================ ===
The second part describes the Object File information and the system behavior of creating a running program. Some of information is suitable for all systems, and other information is related to specific processors.
Executable and shared Object File static depicts the program. In order to perform such programs, the system uses these files to create dynamic program performance, or process images. A process image is used to save its code, data, stack, etc. The main chapter of this part discusses the following.
* Program header. This chapter adds the first part, describes the Object File structure related to the program. That is, the main data structure, program header, and positioning segment image are also required to create a memory image for the program.
* Loading program (Program Loading). When a given Object File, the system in order to run it to load it into memory.
* Dynamic linking. After the program is loaded, the system must complete the process of the process image by resolving the symbol reference problem between the Object File of the process.
Note: The ELF constant of the processor range is a naming convention. For example, DT_, PT_, for a specific processor extension, combine the name of the processor (such as DT_M32_SPECIAL). There is no use of this convention but the pre-existing processor extension is allowed.
Pre-existing extensions ======================= DT_JMP_REL
====================== Program HEADER (program head) ====================== The program header of an executable or shared Object File is a structural array, and each structure describes a segment or other system ready to execute the information you need. An Object File section contains one or more portions (as described below). The program head is meaningful for executable or shared Object File. A file uses the E_PHENTSIZE and E_PHNUM members of the ELF header to specify the program header size it owns. [See "ELF head" in the first part]
Figure 2-1: Program HEADER
typedef struct {Elf32_Word p_type; Elf32_Off p_offset; Elf32_Addr p_vaddr; Elf32_Addr p_paddr; Elf32_Word p_filesz; Elf32_Word p_memsz; Elf32_Word p_flags; Elf32_Word p_align;} Elf32_Phdr;
* p_type
The member pointed out what type of segment of this array is described, or how to explain the information of the array element. Type values and meanings as described below.
* p_offset
The member gives the offset of the resident location of the segment relative to the start of the file.
* p_vaddr
The member gives the first byte address in the memory.
* p_paddr
In a physical address positioning, the member is preserved for the physical address of the segment. Since SYSTEM V ignores the physical address location of the application, the member is not specified for executable files and shared Object.
* p_filesz
The member gives the number of bytes of the paragraph in the file image; it may be 0. * P_memsz
This member gives the number of bytes of the paragraph in the memory image; it may be 0. * P_flags
The member gives the symbol related to this paragraph. The defined flag value is as follows.
* p_align
As mentioned in the later "Load Program" section, the loadable process segments must have the appropriate P_VADDR, P_OFFSET value, and take the size of the size. The member gives this segment to arrange values in memory and files. 0 and 1 indicate that it doesn't need to be arranged. Otherwise, p_align must be the power of positive 2, and p_vaddr should be equal to P_OFFSET model P_ALIGN.
Some entry describes the process segment; other additional information is provided and there is no process image. The inlet that has been defined can appear in any order unless it is clearly declared. Behind the paragraph value; other values remain in the future for other purposes.
Figure 2-2: Segment Types, P_Type
Name value ==== ===== pt_null 0 pt_load 1 pt_dynamic 2 pt_interp 3 pt_note 4 pt_shlib 5 pt_phdr 6 pt_loproc 0x700000 pt_hiProc 0x7fffffff * pt_null
The array element is not used; other member values are undefined. This type allows the program header to ignore the entrance.
* Pt_Load
This array element specifies an amount of loadable segment, described by p_filesz and p_memsz. The byte in the file is mapped to the memory segment. If the memory size (P_MEMSZ) is larger than the file size (p_filesz), the multi-byte is maintained as 0 in the initialization area of the quadrature. The size of the file will not be larger than the memory size. In the program header, the portable sector entry is arranged in ascending order in P_VADDR.
* Pt_dynamic
This array element specifies dynamic link information. See the "Dynamic Part" later to get more information.
* Pt_interp
This array element specifies the location and size of a null-terminal type (as an interpretation). This type of segment is only meaningful to the executable file (although it may happen on a shared object); it can only appear once in a file. If it appears, it must first enable in the portable portable port. See the "Program Interpreter" later to get more information.
* Pt_note
The array element specifies the position and size of the auxiliary information. See the "Note Part" later to get details.
* Pt_shlib
This segment type is reserved and has an undetected semantic. Procedures for this type of array element do not comply with ABI.
* Pt_phdr
The array element (if any) specifies the location and size of the program header table itself (including in the file and in the memory image of the program). Furthermore, it is only valid when the program header is part of the program memory image. If it appears, it must first be in portable portions. See the "Program Interpreter" later to get more information.
* PT_LOPROC THROUGH PT_HIPROC
The value in this range retains the semantics for a particular processor.
Note: All block types of all program headers are optional unless otherwise required. That is, the program header of a file may only contain elements related to its content.
Base Address
The Object File that can perform and shared has a base address that is the minimum virtual address associated with the Object File of the program. One of the applications of the base is to focus on the memory image of the program during the dynamic link.
An executable Object File or a shared base address of the Object File is calculated from three values when executed: the memory load address, the maximum value of the page size, and the minimum virtual address of the program. As described in "Program Load", virtual addresses in the program head may be different in the actual virtual address in the memory image of the program. In order to calculate the base address, the memory address associated with the minimum value of the PT_LOAD segment p_vaddr must be determined. The method of obtaining the base address is to cut the memory address to the closest integer multiple of the maximum page size. The memory address and p_vaddr values may match may not match due to the file type loaded into the memory. As described in "Section" in the first part, .bss Section has the type of SHT_NOBITS. Although it does not take up space in the file, it works in the memory image of the segment. Typically, the data that has not been initialized is residing in the tail, thus making P_MEMSz in the related program header elements than P_Filesz.
Note Section
Sometimes suppliers or system designers need to mark an Object File with a specific information so that other programs check their compatible consistency, and so on. The program lead elements of the SHT_Note type section and the PT_Note type can be used for this purpose. The annotation information in Section and program heads contains any number of portions, and each entry format is a 4-byte array corresponding to a specific processor format. The following tags help explain the organization form of comment information, but these tags are not part of the specification.
Figure 2-3: Note Information
Namesz Descsz Type Name ... desc ...
* Namesz and name
The first byte of Namesz in the name contains a null-terminated character that expresses the owner or originator of the entrance. There is no formal mechanism to avoid name conflicts. For convention, the supplier uses their own name, such as "XYZ Computer Company", as a logo. If the name is not provided, the Namesz value is 0. If necessary, determine the description information 4-byte alignment. Such fill information is not included in Namesz.
* Descsz and DESC
The design of Descsz in DESC contains annotation descriptors. ABI does not place any system parameters in a descriptor content. If there is no descriptor, Descsz will be 0. If necessary, determine the description information 4-byte alignment. Such fill information is not included in the Descsz.
* Type
This Word gives an explanation of a descriptor. Each created (Originator) controls its own type; there is possible to exist for a variety of explanations of single type values. Therefore, a program must identify the name and its type to understand a descriptor. This time the type must be non-negative. ABI does not define the meaning of the descriptor.
For example, the following interpretation includes two inlets.
Figure 2-4: EXAMPLE Note Segment
0 1 2 3 ------------------- Namesz 7 Descsz 0 No Descriptor Type 1 Name X Y Z SPC C O / 0 Pad Namesz 7 Descsz 8 TYPE 3 Name X YZ SPC C O / 0 Pad Desc Word0 Word1 Note: There is no name (Namesz == 0), there is a zero-length name (Name [0] == '/ 0') There is no type to define it. All other names must have at least one non-empty character.
Note: The annotation information is optional. The emergence of annotations does not affect the ABI consistency of a program, provided that this information does not affect the execution behavior of the program. Otherwise, the program will not follow ABI and will appear undefined behavior.
===================== Program loading (program load) ======================
When creating or adding a process image, the system will copy a file to a virtual memory segment. When does the system actually read files depend on the execution behavior of the program, the system is loaded, and so on. A process only requires a physical page when you need to reference a logical page, and the actual process usually leaves a number of uncommon pages. Therefore, delaying physical reads often avoid these conditions, improve the characteristics of the system. In order to achieve this effect, the executable and shared Object File must have a segment image of the file offset and virtual addresses such as page size to take a mode.
Virtual addresses and file offset are powered by 4KB (0x1000) or large power in the SYSTEM V structure. Since 4KB is the largest page size, the file must be suitable for the page regardless of the physical page size.
Figure 2-5: Executable file
File offset file virtual address ============================== 0 Elf Header program header Table other information 0x100 text segment 0x8048100 ... 0x2BE00 BYTES 0X8073EFF 0x2BF00 DATA segment 0x8074f00 ... 0x4e00 Bytes 0x8079cff 0x30d00 Other Information ... Figure 2-6: Program HEADER Segments (program header)
Member Text Data ====== ==== ==== p_type PT_LOAD PT_LOAD p_offset 0x100 0x2bf00 p_vaddr 0x8048100 0x8074f00 p_paddr unspecified unspecified p_filesz 0x2be00 0x4e00 p_memsz 0x2be00 0x5e24 p_flags PF_R PF_X PF_R PF_W PF_X p_align 0x1000 0x1000
Although the file offset and virtual addresses in the example are suitable for mold 4KB in both text and data, there are still 4 files pages to mix code and data (depending on the size of the page size and the size of the file system block).
* The first text page contains the ELF header, program head, and other information. * The last text page contains a copy of a data start. * The first data page has a copy of the end of the text. * The last data page may contain file information that is not related to the running process.
In theory, the difference between the system forces the mid-memory paragraph; the segment address is adjusted to adapt to each logical page has a simple permission collection in the address space. In the above example, file locations containing text ends and data will be mapped twice: on a virtual address for text and another virtual address is data.
The end of the data segment needs to be specially processed for uninitialized data (the system is defined at 0 value). Therefore, if a file contains the last data page of the information is not in the logical memory page, the unrelated data should be set to 0 (herein referring to the content of the unknown executable). In the other three pages, "Impurities" is not part of the process image; whether the system wiped them is not specified. The memory image of the following programs assumes a 4kb page.
Figure 2-7: Process Image Segments (Process Image Segment)
Virtual address contents segment ===================================================================================================================================================== # padding 0x100 bytes 0x8074000 Text padding Data 0xf00 bytes 0x8074f00 Data segment ... 0x4e00 bytes 0x8079d00 Uninitialized data 0x1024 zero bytes 0x807ad24 Page padding 0x2dc zero bytes executable files and share files differ in terms of load segments. Typically, the executable file segment contains absolute code. In order to make the process correctly, these sections must reside at the virtual address of the executable. Therefore, the system uses the constant P_VADDR as the virtual address.
On the other hand, the shared file segment contains code-independent code. This makes the virtual address of the corresponding segments of different processes vary, and does not affect execution. Although the system selects the virtual address for each process, it also maintains the relative position of each segment. Because the location-independent code uses the relative address between segments, the different virtual addresses in the memory must match the virtual address in the file. The following table gives several processes possible shared object virtual addresses, demonstrates the constant relative positioning. The table also demonstrates the calculation of the base address.
Figure 2-8: Example Shared Object Segment Addresses
Sourc Text Data Base Address ===== ==== ==== ============ File 0x200 0x2a400 0x0 Process 1 0x80000200 0x8002a400 0x80000000 Process 2 0x80081200 0x800ab400 0x80081000 Process 3 0x900c0200 0x900ea400 0x900c0000 Process 4 0x900c6200 0x900f0400 0x900c6000
==================== Dynamic Linking (dynamic link) ===================== one can be implemented The file may have a PT_INTERP program lead element. During Exec (ba_OS), the system retrieves a path name from the PT_INTERP segment and creates an initial process image from the segment of the interpreter file. That is, the system is "written" a memory image, not a segment image of the original executable. The interpreter is responsible for receiving the control of the system and provides an environment variable for the application.
The interpreter uses one of the two methods to receive the control of the system. First, it receives a file descriptor to read the executable, positioned at the beginning. It can use this file descriptor to read and / or map the segments of the executable to memory. Second, dependent on the format of the executable, the system will load this executable file to memory instead of a file descriptor to the interpreter. With the abnormal file descriptor exception, the initial process declaration of the interpreter should match the content that the executable should receive. The interpreter itself does not require a second interpreter. An interpreter may be a shared object or an executable file.
* A shared object (usual) is not related to the location when it is loaded, and each process may be different; the system is created and related services in the dynamic segment used in MMAP (Ke_OS). Thus, an interpreter of a shared object will not conflict with the original segment address of the original executable file.
* A executable file is loaded to a fixed address; the system uses the virtual address in the program headheet to create a segment. Thus, a virtual address of an executable file interpreter may conflict with the first executable file; this conflict is solved by the interpreter.
Dynamic Linker (dynamic linker)
When an executable is created using a dynamic link mode, the linker adds a PT_INTERP type element to the executable, telling the system to perform dynamic linkers as the interpreter of the program.
Note: The dynamic linker provided by the system is related to a particular processor.
EXEC (ba_OS) and dynamic linkers cooperate to create a process, must have the following action:
* Add the memory segment of the executable to the process image; * Add the memory segment of the shared object to the process image; * relocate the executable and its shared object; * If there is a read executable The file descriptor is passed to the dynamic linker, then turn off it. * Transfer control to the program, just like the program has been directly received from EXEC (Ba_OS).
The linker also builds a variety of executable files and shared object files for dynamic linkers. As is said in the "program head" above, these data resident in the load-bearing segment makes them valid during the execution process. (Retrase
* A .Dynamic section with a sht_dynamic type contains various data. The structure that resides at the beginning of the section contains the address of other dynamic link information.
* SHT_HASH type .hash Section contains a Symbol Hash Table.
* SHT_PROGBITS type .got and .plt section contain two separate Table: global offset tables and process linked tables. The following section demonstrates the dynamic linker to use and change these tables to create a memory image for Object File. Since each of the procedures that follow the ABI inputs basic system services from a shared object library, dynamic linkers are shared during the execution of each program that follows ABI.
As explained like "program load" in the processor supplementary, the shared object may take up different virtual memory addresses with the address recorded in the program headheet of the file. Dynamic linker restarts the memory image and updates an absolute address before the application gets control. Although the absolute address should be correct in the case where the library is loaded to the address specified by the program header, the usual situation is not the case.
If the process environment [SEE EXEC (BA_OS)] contains a non-zero LD_BIND_NOW variable, the dynamic linker will perform all relocation before controlling to the program. For example, all the following environment portions will specify this behavior.
* LD_BIND_NOW = 1 * ld_bind_now = on * ld_bind_now = OFF
In other cases, ld_bind_now or is not in an environment or is a null value. The dynamic linker can not be urgent to process the process linked table entry, thereby avoiding the symbol parsing and relocation of the function that is not called. See "ProCedure Linkage Table" Get more information.
Dynamic Section (Dynamic Section)
If an Object file is involved in the dynamic connection, its program header will have a type of Pt_Dynamic elements. This "section" contains. Dynamic Section. A _ Dynamic special symbol indicates that the section contains an array of the following structures.
Figure 2-9: Dynamic Structure
TYPEDEF STRUCT {ELF32_SWORD D_TAG; Union {ELF32_SWORD D_VAL; ELF32_ADDR D_PTR;} D_UN;} ELF32_DYN;
EXTERN ELF32_DYN_Dynamic [];
For each of the Object, D_TAG controls the explanation of D_UN.
* D_VAL
Those ELF32_word Object depicts a shaped variable with different interpretation.
* D_PTR
Those ELF32_word Object depicts the virtual address of the program. As mentioned earlier, the virtual address of the file may not match the memory virtual address when executed. When explaining the address included in the dynamic structure, the value and memory based on the original file are explained. For consistency, the file does not include the address in the dynamic structure in the reactive entry.
The following table summarizes Tags that need to be executed and shared Object files. If the Tag is marked as Mandatory, the dynamic connection array of Abi-Conforming files must have a such entry. Similarly, "Optional" means an entry that may have a TAG, but it is not necessary.
Figure 2-10: Dynamic Array Tags, D_TAG
Name value d_un executable shared object ==== ===== ==== ========== ======================================================================================================================================= optional optional DT_PLTRELSZ 2 d_val optional optional DT_PLTGOT 3 d_ptr optional optional DT_HASH 4 d_ptr mandatory mandatory DT_STRTAB 5 d_ptr mandatory mandatory DT_SYMTAB 6 d_ptr mandatory mandatory DT_RELA 7 d_ptr mandatory optional DT_RELASZ 8 d_val mandatory optional DT_RELAENT 9 d_val mandatory optional DT_STRSZ 10 d_val mandatory mandatory DT_SYMENT 11 d_val mandatory mandatory DT_INIT 12 d_ptr optional optional DT_FINI 13 d_ptr optional optional DT_SONAME 14 d_val ignored optional DT_RPATH 15 d_val optional ignored DT_SYMBOLIC 16 ignored ignored optional DT_REL 17 d_ptr mandatory optional DT_RELSZ 18 d_val mandatory optional DT_RELENT 19 d_val mandatory optional DT_PLTREL 20 d_val optional optional DT_DEBUG 21 d_ptr 22 ignored optional optional optional ignored DT_TEXTREL DT_JMPREL 23 d_ptr optional optional DT_LOPROC 0x70000000 unspecified unspecified unspecified DT_HIPROC 0x7fffffff unspecified unspecified unspecified * DT_NULL
An entry of a DT_NULL mark indicates the end of the _ Dynamic array.
* DT_Needed
This element holds the offset of the string table ending with NULL, and those strings are the name of the required library. This offset is an index of the table of dt_strtab as the entrance. Look at "Shared Object Dependencies] More information about those names. Dynamic arrays may contain multiple portions of this type. The relevant order of those entrances is important, although they are not important to the relationship between other entrances.
* DT_PLTRELSZ
This element holds a total byte size of the relocation inlet associated with the PLT. If an inlet type DT_Jmprel exists, then DT_PLTRELSZ must also exist. * DT_PLTGOT
This element is saved with the address associated with the PLT and (or) is GOT. Specific detail look at the processor supplement section.
* DT_HASH
This element holds the address of the symbol hash table, which is described in the "hash table". The hash table points to the symbol table referenced by the DT_SYMTAB element.
* DT_STRTAB
This element stores the string address, which is described in the first part, including symbol names, library names, and some other strings in this table.
* DT_SYMTAB
This element holds the address of the symbol table, which is described in the first part, and an ELF32_sym entry is associated with the 32-bit type file.
* DT_RELA
This element holds the address of the focus table, which is described in the first part. In the entrance in the table, there is a clear plus, like the ELF32_rela of the 32-bit type file. An Object file may have a lot of relocation steps. When a relocation table is established as an executable and shared file, the connection editor is connected to a single table. Although those sections are kept independent in the Object file. Dynamic connector only looks a simple table. When the dynamic connector creates a process image for an executable or add a shared object to the process image, it reads a reposition table and performs relevant actions. If the element exists, the dynamic structure must have DT_RELASZ and DT_RELAENT elements. When the reposition of the file is Mandatory, DT_RELA or DT_REL may appear (simultaneous appearance is allowed, but unnecessary).
* DT_RELASZ
This element stores the total byte size of the DT_RELA relocation table.
* DT_RELAENT
This element holds the byte size of the DT_RELA relocation entry.
* DT_STRSZ
This element stores the byte size of the string table.
* DT_SYMENT
This element holds the byte size of the symbolic entrance.
* DT_INIT
This element holds the address of the initialization function, discusses in the "initialization and termination functions" below.
* Dt_fini
This element holds the address of the termination function and discusses in the "initialization and termination function" below.
* DT_SONAME
This element holds a string offset of strings ending with NULL, and those names are the name of shared Object. The offset is the index of the table recorded in the DT_STRTAB portal. About those names See the Shared Object DepENDENCIES section get more information.
* DT_RPATH
This element stores the string of the string of the search directory string with the search library ending with NULL. Discussion in Shared Object Dependencies
* DT_SYMBOLIC
This element that appears in the shared Object library is a reference to change the dynamic connector symbol resolution in the library. Instead of symbol searches in executable, the dynamic connector starts from its own shared Object. If a shared Object provides a reference refer to a reference, the dynamic connector is searched as usual search executable and other shared objects.
* DT_REL
This element is similar to DT_RELA, except that its table has potential plus, just like the 32-bit file type ELF32_rel. If this element exists, its dynamic structure must also have the elements of DT_RELSZ and DT_RELENT at the same time.
* DT_RELSZ
This element holds the total byte size of the DT_REL relocation table.
* DT_Relent
This element is stored in the byte size of DT_Relent redirects.
* DT_PLTREL
The member indicates the type of relocation inlet pointing to PLT. Suitably, D_VAL members save DT_REL or DT_RELA. All relocations in a plt must use the same conversion. * DT_DEBUG
The member is debugged. Its content is not specified by ABI; the program access to the entry is not Abi-Conforming.
* DT_Textrel
As pointed out in the middle of the program header, the lack of representatives of this member does not reset the entry to change the modification of the non-write. If the member exists, one or more relocation portals may request to modify a non-write, and the dynamic connector can be prepared.
* DT_JMPREL
If there is, its entry D_PTR member saves the address of the ingredient (the inlet separately associates the PLT). If the Lazy mode is opened, then the relocation entry separating them allows the dynamic connector to ignore them when the process is initialized. If the entry exists, the associated type entry DT_PLTRELSZ and DT_PLTREL must exist.
* DT_LOPROC THROUGH DT_HIPROC
The variables within this range are specially reserved for special processors. In addition to the DT_NULL element at the end of the array, the inlet may appear in any order in the order of the DT_NEEDED element. The TAG value that is not present in the table is retained.
Shared Object Dependencies (Shared Object Relationship)
When the connector processes a document library, it takes out members in the library and copies them into an output Object file. When there is no dynamic connector, those static connection services are available. Sharing Object also provides services, and the dynamic connector must connect the correct shared object file to the process image you want to implement. Therefore, there is a clear dependence between executable files and shared Object files.
When the dynamic connector creates a memory segment for an Object file, the dependency (record in the dynamic structure DT_NEEDEDED) indicates which objects are required to serve the program. The dynamic connector can build a complete process image by repeated connection references and their dependencies. When a symbol is resolved, the dynamic connector checks the symbol table with a width priority search (in other words, it first views your own symbolic table in your own, then the top DT_Needed inlet (in order The symbol table, then the second level of DT_Needed inlet, and push it according to the class. Sharing Object files must be readable for the process; other permissions are unnecessary.
Note: Even if a shared Object is referenced multiple times (in the dependenher relational table), the dynamic connector only connects it to the process.
The name in the dependency list is copied by the DT_soname string, and the pathname when the Object file is created. For example, a dynamic connector creates an executable (using a lib1 shared file with DT_SONAME entry) and a shared Object library named / usr / lib / lib2, then executable will include in its own dependence list. LIB1 and / USR / BIN / LIB2.
If a shared Object name has one or more backslash characters (/) how place this name, such as the above / usr / lib / lib2 file or directory, the dynamic connector puts the string you as a path name . If the name does not have a backslash character (/), for example, the above lib1, three methods specify the search path of the shared file, as follows:
* First, the dynamic array mark DT_rPath saves the string of the directory list (separated by colon (:)). For example, string / home / dir / lib: / home / dir2 / lib: tells dynamic connector first search / Home / Dir / lib, then search / Home / Dir2 / lib, and then the current directory. * Second, in the process environment (see EXEC (Ba_OS)), there is a variable called LD_Library_path to save the same directory list as above (free with a semicolon (;) and other directory lists). The following variables are equal to the previous example: ld_library_path = / home / dir / lib: / home / dir2 / lib: ld_library_path = / home / dir / lib; / home / dir2 / lib: ld_library_path = / home / dir / lib: / home / DIR2 / LIB: The so the LD_Library_Path directory is searched after the directory points to the DT_RPATH. Although some programs (such as connection editor) different processing semicolons and semicolons, the dynamic connection is not. However, the dynamic connector accepts the semicolon symbol, which is specifically in the above description.
* Finally, if the two directory above finds the failed library that you want to get, the dynamic connector search / usr / lib.
Note: For security reasons, the dynamic connector ignores the search directory specified by the SET-USER and the SET-Group program of LD_Library_path. But it will search for directory and / usr / lib: DT_RPATH.
GLOBAL OFFSET TABLE (GOT Global Offset Table)
Under normal circumstances, the location-independent code does not contain absolute virtual addresses. The global offset table holds an absolute address in private data, so addresses should be used, rather than the location-independent, and program code segment sharing capacity compromise. A program references its GOT (global offset table) to use location-independent addresses and extract absolute variables, so repositioning locations independent reference to an absolute position.
At the beginning, the GOT (global offset table) saves the information you need to relocate the entry [see "Relocation"] of the first part. After the system creates a memory segment for a loadable Object file, the dynamic connector processes the entry, and those types of R_386_GLOB_DAT indicate the GOT (global offset table). The dynamic connector determines the associated reference variable, calculates their absolute address, and sets the appropriate memory table inlet to the correct variable. Although the absolute address is not known when the Object file is connected to the editor, the connector knows the address of the memory section and can thus calculate the label address there.
If the program needs to access the absolute address of the symbol, then this symbol will have a GOT (global offset table) entry. Because the executable file and shared file have a separate GOT (global offset table), a symbolic address may appear in several tables. The dynamic connector processes all repositioned GOT (global offset tables) before the process image of the process image, so that the absolute address is available when executed.
The inlet 0 of the table is to save the dynamic structural address (refer to _ Dynamic Number). This allows you to find out their own dynamic structure (yet no handling portions) like dynamic connections. These are important for dynamic connectors because it is necessary to initialize themselves without relying on other programs to restart their memory images. In the 32-bit Interl system structure, the population 1 and 2 in the GOT are also retained, and the following procedure connection tables are specifically viewed.
The system can select different memory segments for the same shared object in different programs; it can even select different library addresses for different processes. Even so, once the process image is established, the memory segment does not change the address. As long as one process exists, its memory segment resides in a fixed virtual address. The format and interpretation of the GOT table is the processor. Under the 32-bit Intel architecture, the label _global_offset_table_ may be used to access the table.
Figure 2-11: Global Offset Table
EXTERN ELF32_ADDR _GLOBAL_OFFSET_TABLE_ [];
Number _global_offset_table_ may reside in the middle of .got section, allowing negative and non-negative subscript indexes.
Procedure Linkage Table (PLT Process Connection Table)
Like the got relocation, the location-independent address is calculated as an absolute address, the PLT process connection table retransmission position is unrelated to an absolute address. From an executable or shared Object file to another, the connection editor does not resolve the execution transmission (eg, the call of the function). Therefore, the connection editor arranges the passage of the program to the port in the PLT. Under the System V system, the PLT exists in shared text, but the address they use is in the private GOT. The symbolic connector determines the absolute address of the target and modifies the GOT memory image. Therefore, in the case where there is no sharing of the position, the shared ability of the program text is not accepted. The dynamic connector can relocate the population.
Figure 2-12: Absolute procedure linkage table {*} Absolute process connection table
.Plus_4 jmp * got_plus_4 jmp * got_plus_8 nop; NOP NOP; NOP. PLT1: JMP * Name1_in_got pushl $ OFFSET JMP .plt0 @ Pc .plt2: jmp * name2_in_got pushl $ OFFSET JMP .plt0 @ pc ...
Figure 2-13: Position-Independent ProcedureLinkage Table Location Unrelated (Or Location Independent) Process Connection Table .plt0: Pushl 4 (% EBX) JMP * 8 (% EBX) NOP; NOP NOP; NOP. PLT1: JMP * Name1 @ got (% EBX) Pushl $ offset jmp.plt0 @ pc .plt2: jmp * name2 @ got (% EBX) Pushl $ OFFSET JMP .plt0 @ pc ...
Note: As shown, the PLT instruction uses a different operand address, and the absolute code and the code-independent code. However, their interface is the same for the dynamic connector.
The following steps, dynamic connectors and program collaboration (Cooperate) parses the symbol references via PLT and GOT.
1. When creating a program's memory image, the Dynamic Connector sets the second and third ports for special variables in GOT. There is more explanations about those variables.
2. If the PLT is not related to the location, then the address of the GOT must remain in% EBX. The object files shared in the process image have its own PLT, and only in the same Object file, control is transmitted to the PLT entry. Thus, the function to be called is responsible to set the PLT address to the register before calling the PLT entry. 3. For example, if the program call function name1, its transfer is controlled to the label .plt1.
4. The first instruction jumps to the Name1 address of the GOT entry. When you first, the GOT saves the address of the PUSH1 instruction instead of the real Name1 address.
5. Therefore, the program is pressed into a repositioned offset in the stack. The offset of the relocation is a 32-bit, non-negative byte offset (from the positioning representation). The assigned relocation entry will be a R_386_JMP_SLOT type, which indicates the GOT entry (used in the previous JMP instruction). The relocation entry also contains an index of a symbol table, so tells the dynamic connector which symbol is to be referenced, here is Name1.
6. After pressing a relocated offset of press (PUSH), the program jumps to .plt0, the first inlet in the PLT. The Push1 instruction places the second GOT entry (GOT_PLUS_4 or 4 (% EBX)) in the stack, therefore, gives the dynamic connector one word authentication information. Then the program jumps to the third GOT entry (got_plus_8 or 8 (% EBX)), it transmits control to the dynamic connector.
7. When the dynamic connector is connected to the control, it expands the stack to view the assigned repositioning entry, find the value of the symbol, store the real Name1 address in the GOT entry, and then transfer the desired destination.
8. Conformity execution of the PLT entry will directly transmit the direct transfer to Name1, without the second call dynamic connector. So, the JMP instruction in .plt1 will go to Name1, replace "falling through" to the Pushl instruction.
The LD_BIND_NOW environment variable can change the behavior of the dynamic connector. If this variable is non-empty, the dynamic connector calculates the PLT entry before the transmission is controlled to the program. In other words, the dynamic connector processing the reset type of R_386_JMP_SLOT is initialized in the process. Otherwise, the dynamic connector calculates the PLT entry lazy, postponed to the symbol resolution and relocation until the first execution of a table entry.
Note: In general, binding with lazy (Lazy) is an improvement to full application execution. Because the symbols that are not used will not cause the dynamic connector to do useless work. However, for some applications, two cases use lazy (Lazy) methods are unpopular.
The first initial reference A shared Object function is longer than the later call to spend, because the dynamic connector is adjusted to parse the symbol. Some applications cannot be tolerated. Second, if this error occurs and the dynamic connector cannot resolve the symbol, the dynamic connector will terminate the program. In a lazy (lazy) mode, this may happen at any time. Those who have repeatedly, some applications cannot tolerate. By turning off the lazy (lazy) method, the dynamic connector is forced procedures when the application is processed, and the dynamic connector is forced before the application is processed.
Hash Table (hash table)
The hash table supports the symbolic access to the Hash table of ELF32_WORD OBJECT. The label appears to help explain the organization of the hash table, but they are not part of the specification.
Figure 2-14: Symbol Hash Table
Nbucket nchain bucket [0] ... bucket [nbucket - 1] chain [0] ... chain [nchain - 1] BUCKET array contains NBucket portals, and the chain array contains Nchain entry; index starts from 0. BUCKET and CHAIN save the index of the symbol table. The Chain gossip is similar to the symbol table. The number of symbol table portals should be equal to nchain; so the index of the symbol table also selects the entrance to the Chain table. A hash function (as follows) accepts a symbolic name and returns a value of the bucket index that can be used by the computer. Therefore, if a hash function returns some of the values of the name to X, BUCKET [X% NBucket] will give an index y (both the index of the symbol table and the CHAIN table). If the symbol table inlet is not expected, Chain [Y] gives the inlet of the next symbol table (using the same hash variable). You can chain along the CHAIN until the symbol table entry of the desired name is selected or in the entry of STN_UNDEF.
Figure 2-15: Hashing function
Unsigned long elf_hash (const unsigned char * name) {unsigned long h = 0, g; while (* name) {h = (h << 4) * Name ; if (g = h & 0xf0000000) h ^ = g> > 24; h & = ~ g;} Return H;
Initialization and Termination functions initialization and termination functions
After dynamically connecting the wife to establish a process image and perform relocation, each shared object gets the appropriate opportunity to perform some initials code. The initialization function is not called in a special order, but all shared Object initialization occurs before the execution program gets control.
Similarly, shared Object may include a termination function, which is executed after the process itself begins (in Atexit (Ba_OS) mechanism).
Sharing Object assigns its initialization and termination functions by setting DT_INIT and DT_FINI in the dynamic structure, as described in the dynamic section section of the Dynamic section. Typically, those function code exist. Init and .fini section, the first part of "section" has been mentioned.
Note: Although the termination processing of Atexit (Ba_OS) can generally be completed, it is not guaranteed to be executed on the dead process. Special, if _exit is called (see exit (ba_OS)) or if the process is dead, the process is not to perform termination processing. Because it receives a signal, the signal can capture or ignore.
_____________________________________________________
3. C Library
_____________________________________________________
========================== c library =========================================================================================================================================================================================================================== ===== C library, libc, contains all symbols (included in libsys), in addition, the run functions listed in the two tables below. The run function in the first table is the ANSI C standard.
Figure 3-1: Libc Contents, Names without Synonyms
abort fputc isprint putc strncmp abs fputs ispunct putchar strncpy asctime fread isspace puts strpbrk atof freopen isupper qsort strrchr atoi frexp isxdigit raise strspn atol fscanf labs rand strstr bsearch fseek ldexp rewind strtod clearerr fsetpos ldiv scanf strtok clock ftell localtime setbuf strtol ctime fwrite longjmp setjmp strtoul difftime getc mblen setvbuf tmpfile div getchar mbstowcs sprintf tmpnam fclose getenv mbtowc srand tolower feof gets memchr sscanf toupper ferror gmtime memcmp strcat ungetc fflush isalnum memcpy strchr vfprintf fgetc isalpha memmove STRCMP VPRINTF FGETPOS ISCNTRL MEMSET STRCPY VSPRINTF FGETS ISDIGIT MKTIME STRCSPN WCSTOMBS FOPEN ISGRAPH PERROR STRLEN WCTOMB FPRINTF Islower Printf Strncat
Plus, libc saves the following services.
Figure 3-2: libc Contents, Names with Synonyms__assert getdate lockf ** sleep tell ** cfgetispeed getopt lsearch strdup tempnam cfgetospeed getpass memccpy swab tfind cfsetispeed getsubopt mkfifo tcdrain toascii cfsetospeed getw mktemp tcflow _tolower ctermid hcreate monitor tcflush tsearch cuserid hdestroy nftw tcgetattr _toupper dup2 hsearch nl_langinfo tcgetpgrp twalk fdopen isascii pclose tcgetsid tzset __filbuf isatty popen tcsendbreak _xftw fileno isnan putenv tcsetattr __flsbuf isnand ** putw tcsetpgrp fmtmsg ** lfind setlabel tdelete
** = function is at level 2 in the svid Issue 3 and the At level 2 in the ABI.
The label listed above synonyms is included in the
In the routine columns, there is no definitions below elsewhere.
INT __FILBUF (file * f); this function returns the next Input Character for F, Filling ITS Buffer AS Appriate. It Returns EOF IF AN ERROR OCCURS.
int __flsbuf (int x, FILE * f); This function flushes the output characters for f as if putc (x, f) had been called and then appends the value of x to the resulting output stream It returns EOF if an error occurs. And x Otherwise.
INT _XFTW (int, char *, int (*) (char *, struct stat *, int); calls to the ftw (ba_lib) Function Are Mapped to this function when applications are compiled. this function is identical to ftw (Ba_lib), Except That _xftw () Takes An Interposed First Argument, Which Must Have The Value 2. To learn more about Svid, ANSI C, POSIX, you can see other library section section of this chapter. There is more description after the section "System Data Interfaces".
Global Data Symbols Global Data Symbol
The libc library requires some external global data symbols (defined for its own regular work). All data symbols requested to the libsys library must provide libc to provide data symbols in the table below.
The officially defined data Object is described by their symbolic description, see the SYSTEM V interface definition, the third version, or the data definitions section of Chapter 6 (Supplement on the appropriate processor to System V ABI).
In the form of the entrance in the table below, there is
Figure 3-3: LIBC Contents, Global External Data Symbols
Getdate_err Optarg_Getdate_err Opterr__iob Optind Optopt
