java.lang.Object | |
↳ | com.pnfsoftware.jeb.core.units.codeobject.ELF |
ELF constants and static utility methods. Refer to:
Nested Classes | |||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|
enum | ELF.SymbolLocality | Symbol locality (external, internal). | |||||||||
enum | ELF.WellKnownSection | Enumeration of common well-known ELF sections along with their expected type. |
Fields | |||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|
public static byte[] | ElfMagic | ||||||||||
public static int | ElfMagicIntBE | ||||||||||
public static int | ElfMagicIntLE |
Public Constructors | |||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|
ELF() |
Public Methods | |||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|
static int | Force_SE(int operand, int opSize) | ||||||||||
static long | SE(long operand, int opSize) | ||||||||||
static String | getArmAttributeTagString(int tag) | ||||||||||
static String | getDT(int tag) | ||||||||||
static String | getELFClassString(int id) | ||||||||||
static String | getELFDataString(int id) | ||||||||||
static String | getEMString(int id) | ||||||||||
static String | getETString(int id) | ||||||||||
static String | getEVString(int id) | ||||||||||
static String | getNoteAndroidVersionString(byte[] descData, ByteOrder order) | ||||||||||
static String | getNoteGnuABIString(byte[] descData, ByteOrder order) | ||||||||||
static String | getNoteTypeString(String name, int type) | ||||||||||
static String | getOSABIString(int osabi) | ||||||||||
static String | getPFString(int programFlags) | ||||||||||
static String | getPTString(int programType) | ||||||||||
static String | getPTString(int programType, int emachine) | ||||||||||
static String | getRTString(ProcessorType proctype, int id) | ||||||||||
static String | getSHFString(int id) | ||||||||||
static String | getSHFStringFlags(int flags) | ||||||||||
static String | getSHNString(int id) | ||||||||||
static String | getSHTString(int id) | ||||||||||
static String | getSTBString(int id) | ||||||||||
static String | getSTTString(int id) | ||||||||||
static String | getSTVString(int v) | ||||||||||
static ELF.WellKnownSection |
getSection(int type, String name)
Retrieve the well-known ELF section or null if unknown
| ||||||||||
static String | getX86RTString(int id) | ||||||||||
static int | high(int x) | ||||||||||
static boolean | isRT_GLOB_DAT(ProcessorType proctype, int relocationType) | ||||||||||
static boolean | isRT_JUMP_SLOT(ProcessorType proctype, int relocationType) | ||||||||||
static int | relocate(int id, int A, int ABitCount, int AHL, int P, int S, int G, int GP, int GP0, int EA, int L, ELF.SymbolLocality sym) |
[Expand]
Inherited Methods | |||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|
From class
java.lang.Object
|
If present, this entry's d_ptr member holds the address of relocation entries associated solely with the procedure linkage table. Separating these relocation entries lets the dynamic linker ignore them during process initialization, if lazy binding is enabled. If this entry is present, the related entries of types DT_PLTRELSZ and DT_PLTREL must also be present.
This member specifies the type of relocation entry to which the procedure linkage table refers. The d_val member holds DT_REL or DT_RELA, as appropriate. All relocations in a procedure linkage table must use the same relocation.
This element holds the size, in bytes, of the DT_REL relocation entry.
Address of dynamic string table. (Not offset!)
This element holds the size, in bytes, of a symbol table entry
This element holds the address of the symbol table, described in the first part of this chapter, with Elf32_Sym entries for the 32-bit class of files and Elf64_Sym entries for the 64-bit class of files.
This element holds the address of the SHT_SYMTAB_SHNDX section associated with the dynamic symbol table referenced by the DT_SYMTAB element.
Absence of this indicates no relocs should apply to a nonwritable segment
Core file
Shared object file
Executable file
Operating system-specific
Processor-specific
Operating system-specific
Processor-specific
Relocatable file
The array element specifies a loadable segment, described by p_filesz and p_memsz. The bytes from the file are mapped to the beginning of the memory segment. If the segment's memory size is larger than the file size, the extra bytes are defined to hold the value 0 and to follow the segment's initialized area. The file size may not be larger than the memory size. Loadable segment entries in the program header table appear in ascending order, sorted on the vaddr member
The array element, if present, specifies the location and size of the program header table itself, both in the file and in the memory image of the program. This segment type may not occur more than once in a file. Moreover, it may occur only if the program header table is part of the memory image of the program. If it is present, it must precede any loadable segment entry. See "Program Interpreter" in the appendix at the end of Book III for further information.
The following relocations are GNU extensions.
The link editor creates this relocation type for dynamic linking. Its offset member gives the location of a procedure linkage table entry. The dynamic linker modifies the procedure linkage table entry to transfer control to the designated symbol's address.
More TLS relocations
TLS relocations
This value specifies absolute values for the corresponding reference. For example, symbols defined relative to section number SHN_ABS have absolute values and are not affected by relocation.
Symbols defined relative to this section are common symbols, such as FORTRAN COMMON or unallocated C external variables.
SHN_LOOS through SHN_HIOS: Values in this inclusive range are reserved for operating system-specific semantics.
SHN_LOPROC through SHN_HIPROC: Values in this inclusive range are reserved for processor-specific semantics.
This value specifies the upper bound of the range of reserved indexes. The system reserves indexes between SHN_LORESERVE and SHN_HIRESERVE, inclusive; the values do not reference the section header table. The section header table does not contain entries for the reserved indexes.
SHN_LOOS through SHN_HIOS: Values in this inclusive range are reserved for operating system-specific semantics.
SHN_LOPROC through SHN_HIPROC: Values in this inclusive range are reserved for processor-specific semantics.
This value specifies the lower bound of the range of reserved indexes.
This value marks an undefined, missing, irrelevant, or otherwise meaningless section reference. For example, a symbol ``defined'' relative to section number SHN_UNDEF is an undefined symbol.
This value is an escape value. It indicates that the actual section header index is too large to fit in the containing field and is to be found in another location (specific to the structure where it appears).
The section holds information for dynamic linking. Currently, an object file may have only one dynamic section, but this restriction may be relaxed in the future.
SHT_SYMTAB and SHT_DYNSYM: These sections hold a symbol table. Currently, an object file may have only one section of each type, but this restriction may be relaxed in the future. Typically, SHT_SYMTAB provides symbols for link editing, though it may also be used for dynamic linking. As a complete symbol table, it may contain many symbols unnecessary for dynamic linking. Consequently, an object file may also contain a SHT_DYNSYM section, which holds a minimal set of dynamic linking symbols, to save space. See ``Symbol Table'' below for details.
This section contains an array of pointers to termination functions. Each pointer in the array is taken as a parameterless procedure with a void return.
This section defines a section group. A section group is a set of sections that are related and that must be treated specially by the linker. Sections of type SHT_GROUP may appear only in relocatable objects (objects with the ELF header e_type member set to ET_REL). The section header table entry for a group section must appear in the section header table before the entries for any of the sections that are members of the group.
The section holds a symbol hash table. Currently, an object file may have only one hash table, but this restriction may be relaxed in the future.
SHT_LOOS through SHT_HIOS: Values in this inclusive range are reserved for operating system-specific semantics.
SHT_LOPROC through SHT_HIPROC: Values in this inclusive range are reserved for processor-specific semantics.
This value specifies the upper bound of the range of indexes reserved for application programs. Section types between SHT_LOUSER and SHT_HIUSER may be used by the application, without conflicting with current or future system-defined section types.
This section contains an array of pointers to initialization functions. Each pointer in the array is taken as a parameterless procedure with a void return.
SHT_LOOS through SHT_HIOS: Values in this inclusive range are reserved for operating system-specific semantics.
SHT_LOPROC through SHT_HIPROC: Values in this inclusive range are reserved for processor-specific semantics.
This value specifies the lower bound of the range of indexes reserved for application programs.
A section of this type occupies no space in the file but otherwise resembles SHT_PROGBITS. Although this section contains no bytes, the sh_offset member contains the conceptual file offset.
The section holds information that marks the file in some way.
This value marks the section header as inactive; it does not have an associated section. Other members of the section header have undefined values.
This section contains an array of pointers to functions that are invoked before all other initialization functions. Each pointer in the array is taken as a parameterless procedure with a void return.
The section holds information defined by the program, whose format and meaning are determined solely by the program.
The section holds relocation entries without explicit addends, such as type Elf32_Rel for the 32-bit class of object files or type Elf64_Rel for the 64-bit class of object files. An object file may have multiple relocation sections.
The section holds relocation entries with explicit addends, such as type Elf32_Rela for the 32-bit class of object files or type Elf64_Rela for the 64-bit class of object files. An object file may have multiple relocation sections.
This section type is reserved but has unspecified semantics.
The section holds a string table. An object file may have multiple string table sections.
SHT_SYMTAB and SHT_DYNSYM: These sections hold a symbol table. Currently, an object file may have only one section of each type, but this restriction may be relaxed in the future. Typically, SHT_SYMTAB provides symbols for link editing, though it may also be used for dynamic linking. As a complete symbol table, it may contain many symbols unnecessary for dynamic linking. Consequently, an object file may also contain a SHT_DYNSYM section, which holds a minimal set of dynamic linking symbols, to save space.
This section is associated with a section of type SHT_SYMTAB and is required if any of the section header indexes referenced by that symbol table contain the escape value SHN_XINDEX. The section is an array of Elf32_Word values. Each value corresponds one to one with a symbol table entry and appear in the same order as those entries. The values represent the section header indexes against which the symbol table entries are defined. Only if corresponding symbol table entry's st_shndx field contains the escape value SHN_XINDEX will the matching Elf32_Word hold the actual section header index; otherwise, the entry must be SHN_UNDEF (0).
Global symbols are visible to all object files being combined. One file's definition of a global symbol will satisfy another file's undefined reference to the same global symbol.
Local symbols are not visible outside the object file containing their definition. Local symbols of the same name may exist in multiple files without interfering with each other.
Weak symbols resemble global symbols, but their definitions have lower precedence.
An uninitialized common block
Local, absolute symbol that refers to a file.
Conventionally, the symbol's name gives the name of the source file associated with the object file. A file symbol has STB_LOCAL binding, its section index is SHN_ABS, and it precedes the other STB_LOCAL symbols for the file, if it is present.
The symbol is associated with a function or other executable code.
GNU indirect function
The symbol is associated with a data object, such as a variable, an array, etc.
The symbol is associated with a section. Symbol table entries of this type exist primarily for relocation and normally have STB_LOCAL binding.
Thread local data object
Retrieve the well-known ELF section or null if unknown
type | Section type, see SHT_* |
---|---|
name | Section name, starting by "." |