Linux executable file format detailed

Under Linux, the target file, the shared object file, and the executable file are stored using the elf file format. After compiling, the program outputs the target file, which is then linked to produce the executable file or the shared object file. The elf files used under Linux and the PE files used by the Windows operating system are all evolved from the COFF file format of the UNIX system.

Let's start by understanding some basic ideas.

First, the most important idea is that when a program is converted from a human-readable format to a binary format that is executed by the operating system, the code and data are stored separately, so there are several reasons for this design:

1, after the execution of the program, code and data can be mapped to different properties of virtual memory. Because the code is generally read-only, and the data is readable and writable;

2, the modern CPU has a strong cache system. Program and code separation can improve the local nature of the program, increase the probability of cache hit;

3. One of the most important reasons is that when there are multiple copies of the program running, the read-only portion can be kept in memory only, which saves memory significantly.

In the definition of Elf, the place where they are stored separately is called a section, which is a paragraph.

An important segment of an elf file includes:

. Text segment: Store read-only programs

. Data segment: Store initialized global variables and static variables

. BSS: Stores uninitialized global variables and static variables because the values of these variables are 0, so this segment does not occupy space in the file

. Rodata segment: Store read-only data, such as String constants

Let's use an example to see what the format of the elf file is. First, write a C program under Linux: SIMPLESECTION.C

int printf (const char *format, ...); int global_init_var = 16;int global_unint_var;void func1 (int); int main () {    static int static_var = -32;    static int static_var_uninit;    int a = 1;    int b;    Func1 (Static_var + Global_init_var + A + b);    return A;} void func1 (int i) {    printf ("%d\n", I);}

Then, the target file is generated:

[[email protected] program]# gcc-c simplesection.c[[email protected] program]# file simplesection.osimplesection.o:elf 32-bit LSB relocatable, Intel 80386, version 1 (SYSV), not stripped

The result of the file command also tells us that this is a 32-bit Elf file with the type relocatable, which is relocatable. So the target file is also called a relocatable file.

Elf file is the beginning of the elf file header information, 32 bits have 52 bytes of composition. We can use the Readelf tool to see:

[[email protected] program]# readelf-h simplesection.oelf header:magic:7f 4c 46 01 01 01 00 00 00 00 00 00 00 00                           XX class:elf32 data:2 ' s complement, little endian Version:                       1 (current) Os/abi:unix-system V ABI Version:                           0 Type:rel (relocatable file) Machine:intel 80386 Version: 0x1 Entry Point address:0x0 Start of program headers:0 (bytes into fi Le) Start of section headers:224 (bytes to file) flags:0x0 Size of this header : Bytes Size of program headers:0 (bytes) Number of program headers:0 size of SE Ction headers:40 (bytes) Number of sections Headers:11 section header string Table Index:8

The Entry point address refers to the program entry location, and if it is an executable file, the field will have values;

His previous fields were some description fields;

Start of program headers refers to the starting position of the Header table. The Program Header table is the classification information of elf from the angle of loading view; The structure and Cong are similar;

Start of section headers points out the most important information for elf except for file headers: The starting position of the segment table. Cong contains important information about the names, attributes, sizes, and locations of each segment. The operating system first finds the segment table and then finds each segment based on the information in the paragraph table. Cong is an array-like structure, and the information for a segment is an element of the array.

Size of this header refers to the header file size, 32 bits are 52 bytes, and 0x34 bytes.

Size of program headers refers to the sizes of each header table.

Number of program headers refers to the amount of the Header table.

Size of sections headers refers to the sizes of each segment table;

Number of section headers refers to the quantity of the segment table;

Section header string Table index indicates the subscript in the segment table for the string tables used in the Segment table.

After the file header, followed by the program header, because the target file is not linked, so there is no loading information. We can not pay attention to this thing here, after the special talk about him.

After the program header is the data of each segment, we use the tool to look at:

[[email protected] program]# readelf-s simplesection.othere is one section headers, starting at offset 0xe0:section            Headers: [Nr] Name Type Addr Off Size ES Flg Lk Inf Al [0] NULL   00000000 000000 000000 0 0 0 [1]. Text Progbits 00000000 000034 000020 xx AX 0        0 4 [2]. Rel.text Rel 00000000 0003f4 000010 9 1 4 [3]. Data progbits   00000000 000054 000008 xx wa 0 0 4 [4]. BSS Nobits 00000000 00005c 000004 xx WA 0 0 4 [5]. Rodata Progbits 00000000 00005c 000004 A 0 0 1 [6]. Comment Progbits 0 0000000 000060 00002d MS 0 0 1 [7]. Note. Gnu-stack Progbits 00000000 00008d 000000 0 0 1 [8]. Shstrtab Strtab 00000000 00008    D 000051 0 0 1 [9]. Symtab Symtab 00000000 000298 0000f0 10 4 [ten]. Strtab Strtab 00000000 000388 00006b 0 0 1Key to Flags:w (write), A (all OC), X (Execute), M (merge), S (strings) I (info), L (link order), G (group), X (unknown) O (extra OS processing require d) O (OS specific), p (processor specific)

Each field has the following meanings: Segment ordinal, segment name, segment type, segment virtual address, offset, size, ES, flag, Lk, INF, alignment.

The columns that are not explained can be considered first, and we will focus on several other columns first.

The No. 0 paragraph is to read the subscript without minus 1.

followed by the code snippet, the offset is 0x34, that is, the end of the file header immediately after the code snippet;

After the code snippet, the offset 0x54 is the data segment, which accounts for 8 bytes, which is a global variable and a static variable that has been assigned in the program;

Then there is the. BSS segment, where only a static variable is stored, because the uninitialized global variable is stored by an optimization mechanism. Common paragraph, here can ignore;

Then there is a read-only data segment. Rodata, which is stored in printf inside the%d\n three characters, plus the Terminator, 4 bytes of space

We calculate the total space occupied by these segments according to the Size column (. BSS is not counted in because it does not occupy space):

. Text 0x20

. Data 0x8

. Rodata 0x4

. Comment 0x2d

. Shstrtab 0x51

. Rel.text 0x10

. Symtab 0xf0

. Strtab 0x6b

Each of these sections has a section table element to describe, a total of 11. From the scratch file, the size of each element is 40 bytes. This means that the segment table occupies a total of 0x1b8 bytes of space. And the start address of the segment table is 2 bytes empty due to memory alignment. Because the beginning address of the segment table is the No. 224 byte;

The beginning of the Rel.text boycott also due to memory alignment requirements, an empty byte was made up.

In addition to the header file of the 0x34 bytes, a total of 1028 bytes added up.

[[email protected] program]# Ls-al simplesection.o-rw-r--r--1 root root 1028-16:09 SIMPLESECTION.O

This target file is exactly 1028 bytes in size.