[Eloader] 3. The ELF Header

[m0skit0]

Originally posted by m0skit0 on advancedpsp.tk.
Retrieved by ultimakillz, http://h4ck.fi.st/index.php/topic,79.0.html

So now we need loading the ELF code into memory. How can we do this?

Well first, I'd like to introduce some typedefs for using with ELFs. Very simple ones here:

Code: Select all

typedef unsigned int Elf32_Addr;
typedef unsigned int Elf32_Off;
typedef int Elf32_Sword;
typedef int Elf32_Word;
typedef short int Elf32_Half;
typedef char BYTE;

This said, every ELF file starts with an ELF header, which has the following structure:

Code: Select all

#define EI_NIDENT 16 //Size of e_ident[]
typedef struct
{
    BYTE e_ident[EI_NIDENT];//Magic number
    Elf32_Half e_type;      // Identifies object file type
    Elf32_Half e_machine;   // Architecture build
    Elf32_Word e_version;   // Object file version
    Elf32_Addr e_entry;     // Virtual address of code entry
    Elf32_Off e_phoff;      // Program header table's file offset in bytes
    Elf32_Off e_shoff;      // Section header table's file offset in bytes
    Elf32_Word e_flags;     // Processor specific flags
    Elf32_Half e_ehsize;    // ELF header size in bytes
    Elf32_Half e_phentsize; // Program header size (all the same size)
    Elf32_Half e_phnum;     // Number of program headers
    Elf32_Half e_shentsize; // Section header size (all the same size)
    Elf32_Half e_shnum;     // Number of section headers
    Elf32_Half e_shstrndx;  // Section header table index of the entry associated with the
                            // section name string table.
} Elf32_Ehdr;

Next I'm gonna explain the more important members we have in this structure. Some of them are already explained on the comment, so no need to repeat the same thing again here.

An ELF file is known to have 4 magic initial bytes (we call them magic because they allow us to identify the type of file), which are 0x7F 'E' 'L' 'F'. If this magic number doesn't appear at the start of the file, then no need to continue, it's not an ELF file. So these bytes should appear from e_ident[0] to e_ident[3].

The e_entry member indicates the virtual address for code entry, that is, the first instruction to begin execution of the code. As I already said a few times, in PSP architecture there's no such thing as virtual memory, so we're reffering to real addresses.

The e_phoff member indicates the offset in the ELF file of the program headers table. The program sections contain the code + data required for the code to run properly, and thus should be allocated in RAM. Each program header describes a program section. Afaik, there's only one program header and one program section in PSP ELFs.

The e_shoff indicates the ELF offset for the section header table. This table contains section headers, which describe each ELF section and their attributes. For example, the .sceStub.text section would be described in the section header table.

The e_shstrndx indicates the index in the section header table for the String Table. This table is just a concatenation of various null-terminated strings, that usually holds the name of the sections (such as .sceStub.text ).

Ok so this for ELF header, we'll continue later...

Advertising

[tbg]

Translated into Spanish...

Advertising