A minimal, full and proper ELF file
As a part of the compiler for my homebrew language, Garlic, I have been exploring what’s in an ELF file. That is so I can output a binary file, prepared for execution, as an alternative of relying on an exterior compiler like GCC to do this final step. As a primary step, I’ve hand-generated, byte-by-byte, a small ELF file that may be run on a 64-bit x86-64 Linux set up.
There are some nice assets on the market (truly minimal ELF files for 32-bit architectures, a 64-bit tiny ELF file, a more comprehensive tutorial), however I nonetheless struggled with this train. The rationale was that both the article tried to reduce the info within the file—omitting items which are going to exist in real-world ELF information a compiler would generate—or the article was too detailed. One other concern was that even when the high-level construction was clear, the person bytes weren’t mentioned. I needed to shuttle between these articles and the Linux ELF documentation (man elf).
So right here is my try, with a further twist: every byte within the rationalization is clickable, with references to associated bytes elsewhere within the file.
File overview
On this minimal ELF file, I might be establishing a statically linked executable for an x86-64 Linux set up.
First, an summary, which is one thing I discovered very laborious to grasp from any of the assets I checked out. The ELF file all the time begins with a fixed-size header, which states the areas of the opposite components of the file. The diagram reveals all these references:
-
The ELF header states the place the part and program header tables are, in addition to which entry within the part header desk is the part header string desk.
-
Each the
.textual contentpart header and the executable program section header state the place the.textual contentpart is. -
The
.shstrtabpart header states the place the part header string desk is. -
The assorted part headers index into the part header string desk for the names of the sections.
By altering the references, you’ll be able to place any of those sections wherever within the file! For instance, I may have prevented the crossing of the arrows on the precise if I put the .shstrtab part header earlier than the .textual content part header 🙂
Technically, the part header desk and the part header string desk usually are not wanted, however having them units the stage for including extra sections sooner or later, particularly dynamic linking and debug image sections.
ELF header
As talked about within the overview, the ELF header is a fixed-size part of bytes that specifies how what this file is and the way the remainder of the file is laid out. As a result of the construction of the header is so inflexible, it may be learn with out considerations reminiscent of endianness or what different sections are current within the file.
Magic quantity
"ELF" in ASCII. Identifies this file as an ELF file.
Kind (structure)
64-bit structure
Processor knowledge format
Two’s complement, little-endian
ELF model
Present ELF specfication model
OS ABI
“None”, evquivalent to UNIX – System-V, default model
Padding
Padding till 16 bytes, for future compatibility
Object file sort
Static executable, versus one thing like a shared object (.so file)
File model
“Present” model
Entry level
The place the system ought to switch management when beginning the method. Wanted for executables. Expressed as a digital reminiscence tackle; see each the executable section in this system headers desk and the .textual content part header within the part headers desk beneath for extra particulars.
Program header desk begin
The byte offset, on this file, of the beginning of this system header desk
Part header desk begin
The byte offset, on this file, of the beginning of the part header desk
Processor-specific flags
None outlined by the ELF specs at the moment
ELF header dimension
The scale of the ELF header in bytes
Program header entry dimension
The scale of every program header in this system header desk, in bytes. For 64-bit architectures, this dimension is 56 bytes.
Variety of program headers
The variety of program headers in this system header desk
Part header entry dimension
The scale of every part header within the part header desk, in bytes. For 64-bit architectures, this dimension is 64 bytes.
Variety of part headers
The variety of part headers within the part header desk
Part title string desk index
Which of the part headers factors to the part title string desk, listed from zero.
The part title string desk is itself a piece, which implies a corresponding header reveals up within the part header desk. This index factors out which part header that header is, as a result of the part title string desk is a particular part.
Part header desk
An ELF file is damaged up into a number of sections, every with a special sort and subsequently a special construction. The part header desk lays out the completely different sections within the file, the place they’re and what sort they’re. The sections needn’t seem proper after the desk, nor do they should seem in the identical order as within the desk. The desk will reference the info for every part by offset into the file.
Typical sections in an ELF file embody the .textual content part (containing the code that might be executed), debug symbols and relocation symbols (for dynamic linking). There’s a particular part sort, the part header title desk, that comprises strings with the names of the sections. Solely the .textual content and the part header title desk are included on this file.
.textual content part: part title
The .textual content part is the part of the ELF file containing the executable code that might be loaded into the executable program section. This part is outlined by the next fields:
| Discipline | Worth | Notes |
|---|---|---|
| Title | 1 (".textual content") |
Outlined by an index into the part title string desk, pointing to a null-terminated ASCII string. |
| Kind | PROGBITS |
The loaded program will decide what these bytes imply. The information is opaque to the ELF file. |
| Flags | Allocatable + executable | Loaded into reminiscence throughout course of execution |
| Deal with | 0x4000F8 |
The place the info from this part will find yourself in reminiscence as soon as it’s loaded. Discover this is identical because the tackle of the executable program section. That is outlined as a result of the section is allocatable. |
| Offset | 0xF8 |
The place the info for this part resides inside this file |
| Dimension | 14 |
What number of bytes the part takes up on this file |
| Hyperlink | N/A | Hyperlinks to a different part header by index. The interpretation of this discipline is dependent upon the part sort. For this .textual content part, there is no such thing as a hyperlink as a result of this file represents a static binary. |
| Information | N/A | Any additional data, topic to interpretation based mostly on the part sort. No additional data for this part. |
| Deal with alignment | 0x1000 |
Any alignment constraint, in bytes, for the info on this part. The alignment right here is identical as that of the executable program section. |
| Entry dimension | N/A | For sections that include a desk of fixed-size entries (reminiscent of an emblem desk), this discipline states the scale of these entries in bytes. |
.textual content part: part sort
The .textual content part is the part of the ELF file containing the executable code that might be loaded into the executable program section. This part is outlined by the next fields:
| Discipline | Worth | Notes |
|---|---|---|
| Title | 1 (".textual content") |
Outlined by an index into the part title string desk, pointing to a null-terminated ASCII string. |
| Kind | PROGBITS |
The loaded program will decide what these bytes imply. The information is opaque to the ELF file. |
| Flags | Allocatable + executable | Loaded into reminiscence throughout course of execution |
| Deal with | 0x4000F8 |
The place the info from this part will find yourself in reminiscence as soon as it’s loaded. Discover this is identical because the tackle of the executable program section. That is outlined as a result of the section is allocatable. |
| Offset | 0xF8 |
The place the info for this part resides inside this file |
| Dimension | 14 |
What number of bytes the part takes up on this file |
| Hyperlink | N/A | Hyperlinks to a different part header by index. The interpretation of this discipline is dependent upon the part sort. For this .textual content part, there is no such thing as a hyperlink as a result of this file represents a static binary. |
| Information | N/A | Any additional data, topic to interpretation based mostly on the part sort. No additional data for this part. |
| Deal with alignment | 0x1000 |
Any alignment constraint, in bytes, for the info on this part. The alignment right here is identical as that of the executable program section. |
| Entry dimension | N/A | For sections that include a desk of fixed-size entries (reminiscent of an emblem desk), this discipline states the scale of these entries in bytes. |
.textual content part: part flags
The .textual content part is the part of the ELF file containing the executable code that might be loaded into the executable program section. This part is outlined by the next fields:
| Discipline | Worth | Notes |
|---|---|---|
| Title | 1 (".textual content") |
Outlined by an index into the part title string desk, pointing to a null-terminated ASCII string. |
| Kind | PROGBITS |
The loaded program will decide what these bytes imply. The information is opaque to the ELF file. |
| Flags | Allocatable + executable | Loaded into reminiscence throughout course of execution |
| Deal with | 0x4000F8 |
The place the info from this part will find yourself in reminiscence as soon as it’s loaded. Discover this is identical because the tackle of the executable program section. That is outlined as a result of the section is allocatable. |
| Offset | 0xF8 |
The place the info for this part resides inside this file |
| Dimension | 14 |
What number of bytes the part takes up on this file |
| Hyperlink | N/A | Hyperlinks to a different part header by index. The interpretation of this discipline is dependent upon the part sort. For this .textual content part, there is no such thing as a hyperlink as a result of this file represents a static binary. |
| Information | N/A | Any additional data, topic to interpretation based mostly on the part sort. No additional data for this part. |
| Deal with alignment | 0x1000 |
Any alignment constraint, in bytes, for the info on this part. The alignment right here is identical as that of the executable program section. |
| Entry dimension | N/A | For sections that include a desk of fixed-size entries (reminiscent of an emblem desk), this discipline states the scale of these entries in bytes. |
.textual content part: part tackle
The .textual content part is the part of the ELF file containing the executable code that might be loaded into the executable program section. This part is outlined by the next fields:
| Discipline | Worth | Notes |
|---|---|---|
| Title | 1 (".textual content") |
Outlined by an index into the part title string desk, pointing to a null-terminated ASCII string. |
| Kind | PROGBITS |
The loaded program will decide what these bytes imply. The information is opaque to the ELF file. |
| Flags | Allocatable + executable | Loaded into reminiscence throughout course of execution |
| Deal with | 0x4000F8 |
The place the info from this part will find yourself in reminiscence as soon as it’s loaded. Discover this is identical because the tackle of the executable program section. That is outlined as a result of the section is allocatable. |
| Offset | 0xF8 |
The place the info for this part resides inside this file |
| Dimension | 14 |
What number of bytes the part takes up on this file |
| Hyperlink | N/A | Hyperlinks to a different part header by index. The interpretation of this discipline is dependent upon the part sort. For this .textual content part, there is no such thing as a hyperlink as a result of this file represents a static binary. |
| Information | N/A | Any additional data, topic to interpretation based mostly on the part sort. No additional data for this part. |
| Deal with alignment | 0x1000 |
Any alignment constraint, in bytes, for the info on this part. The alignment right here is identical as that of the executable program section. |
| Entry dimension | N/A | For sections that include a desk of fixed-size entries (reminiscent of an emblem desk), this discipline states the scale of these entries in bytes. |
.textual content part: part offset
The .textual content part is the part of the ELF file containing the executable code that might be loaded into the executable program section. This part is outlined by the next fields:
| Discipline | Worth | Notes |
|---|---|---|
| Title | 1 (".textual content") |
Outlined by an index into the part title string desk, pointing to a null-terminated ASCII string. |
| Kind | PROGBITS |
The loaded program will decide what these bytes imply. The information is opaque to the ELF file. |
| Flags | Allocatable + executable | Loaded into reminiscence throughout course of execution |
| Deal with | 0x4000F8 |
The place the info from this part will find yourself in reminiscence as soon as it’s loaded. Discover this is identical because the tackle of the executable program section. That is outlined as a result of the section is allocatable. |
| Offset | 0xF8 |
The place the info for this part resides inside this file |
| Dimension | 14 |
What number of bytes the part takes up on this file |
| Hyperlink | N/A | Hyperlinks to a different part header by index. The interpretation of this discipline is dependent upon the part sort. For this .textual content part, there is no such thing as a hyperlink as a result of this file represents a static binary. |
| Information | N/A | Any additional data, topic to interpretation based mostly on the part sort. No additional data for this part. |
| Deal with alignment | 0x1000 |
Any alignment constraint, in bytes, for the info on this part. The alignment right here is identical as that of the executable program section. |
| Entry dimension | N/A | For sections that include a desk of fixed-size entries (reminiscent of an emblem desk), this discipline states the scale of these entries in bytes. |
.textual content part: part dimension
The .textual content part is the part of the ELF file containing the executable code that might be loaded into the executable program section. This part is outlined by the next fields:
| Discipline | Worth | Notes |
|---|---|---|
| Title | 1 (".textual content") |
Outlined by an index into the part title string desk, pointing to a null-terminated ASCII string. |
| Kind | PROGBITS |
The loaded program will decide what these bytes imply. The information is opaque to the ELF file. |
| Flags | Allocatable + executable | Loaded into reminiscence throughout course of execution |
| Deal with | 0x4000F8 |
The place the info from this part will find yourself in reminiscence as soon as it’s loaded. Discover this is identical because the tackle of the executable program section. That is outlined as a result of the section is allocatable. |
| Offset | 0xF8 |
The place the info for this part resides inside this file |
| Dimension | 14 |
What number of bytes the part takes up on this file |
| Hyperlink | N/A | Hyperlinks to a different part header by index. The interpretation of this discipline is dependent upon the part sort. For this .textual content part, there is no such thing as a hyperlink as a result of this file represents a static binary. |
| Information | N/A | Any additional data, topic to interpretation based mostly on the part sort. No additional data for this part. |
| Deal with alignment | 0x1000 |
Any alignment constraint, in bytes, for the info on this part. The alignment right here is identical as that of the executable program section. |
| Entry dimension | N/A | For sections that include a desk of fixed-size entries (reminiscent of an emblem desk), this discipline states the scale of these entries in bytes. |
.textual content part: hyperlink
The .textual content part is the part of the ELF file containing the executable code that might be loaded into the executable program section. This part is outlined by the next fields:
| Discipline | Worth | Notes |
|---|---|---|
| Title | 1 (".textual content") |
Outlined by an index into the part title string desk, pointing to a null-terminated ASCII string. |
| Kind | PROGBITS |
The loaded program will decide what these bytes imply. The information is opaque to the ELF file. |
| Flags | Allocatable + executable | Loaded into reminiscence throughout course of execution |
| Deal with | 0x4000F8 |
The place the info from this part will find yourself in reminiscence as soon as it’s loaded. Discover this is identical because the tackle of the executable program section. That is outlined as a result of the section is allocatable. |
| Offset | 0xF8 |
The place the info for this part resides inside this file |
| Dimension | 14 |
What number of bytes the part takes up on this file |
| Hyperlink | N/A | Hyperlinks to a different part header by index. The interpretation of this discipline is dependent upon the part sort. For this .textual content part, there is no such thing as a hyperlink as a result of this file represents a static binary. |
| Information | N/A | Any additional data, topic to interpretation based mostly on the part sort. No additional data for this part. |
| Deal with alignment | 0x1000 |
Any alignment constraint, in bytes, for the info on this part. The alignment right here is identical as that of the executable program section. |
| Entry dimension | N/A | For sections that include a desk of fixed-size entries (reminiscent of an emblem desk), this discipline states the scale of these entries in bytes. |
.textual content part: extra data
The .textual content part is the part of the ELF file containing the executable code that might be loaded into the executable program section. This part is outlined by the next fields:
| Discipline | Worth | Notes |
|---|---|---|
| Title | 1 (".textual content") |
Outlined by an index into the part title string desk, pointing to a null-terminated ASCII string. |
| Kind | PROGBITS |
The loaded program will decide what these bytes imply. The information is opaque to the ELF file. |
| Flags | Allocatable + executable | Loaded into reminiscence throughout course of execution |
| Deal with | 0x4000F8 |
The place the info from this part will find yourself in reminiscence as soon as it’s loaded. Discover this is identical because the tackle of the executable program section. That is outlined as a result of the section is allocatable. |
| Offset | 0xF8 |
The place the info for this part resides inside this file |
| Dimension | 14 |
What number of bytes the part takes up on this file |
| Hyperlink | N/A | Hyperlinks to a different part header by index. The interpretation of this discipline is dependent upon the part sort. For this .textual content part, there is no such thing as a hyperlink as a result of this file represents a static binary. |
| Information | N/A | Any additional data, topic to interpretation based mostly on the part sort. No additional data for this part. |
| Deal with alignment | 0x1000 |
Any alignment constraint, in bytes, for the info on this part. The alignment right here is identical as that of the executable program section. |
| Entry dimension | N/A | For sections that include a desk of fixed-size entries (reminiscent of an emblem desk), this discipline states the scale of these entries in bytes. |
.textual content part: addresss alignment
The .textual content part is the part of the ELF file containing the executable code that might be loaded into the executable program section. This part is outlined by the next fields:
| Discipline | Worth | Notes |
|---|---|---|
| Title | 1 (".textual content") |
Outlined by an index into the part title string desk, pointing to a null-terminated ASCII string. |
| Kind | PROGBITS |
The loaded program will decide what these bytes imply. The information is opaque to the ELF file. |
| Flags | Allocatable + executable | Loaded into reminiscence throughout course of execution |
| Deal with | 0x4000F8 |
The place the info from this part will find yourself in reminiscence as soon as it’s loaded. Discover this is identical because the tackle of the executable program section. That is outlined as a result of the section is allocatable. |
| Offset | 0xF8 |
The place the info for this part resides inside this file |
| Dimension | 14 |
What number of bytes the part takes up on this file |
| Hyperlink | N/A | Hyperlinks to a different part header by index. The interpretation of this discipline is dependent upon the part sort. For this .textual content part, there is no such thing as a hyperlink as a result of this file represents a static binary. |
| Information | N/A | Any additional data, topic to interpretation based mostly on the part sort. No additional data for this part. |
| Deal with alignment | 0x1000 |
Any alignment constraint, in bytes, for the info on this part. The alignment right here is identical as that of the executable program section. |
| Entry dimension | N/A | For sections that include a desk of fixed-size entries (reminiscent of an emblem desk), this discipline states the scale of these entries in bytes. |
.textual content part: part entry dimension
The .textual content part is the part of the ELF file containing the executable code that might be loaded into the executable program section. This part is outlined by the next fields:
| Discipline | Worth | Notes |
|---|---|---|
| Title | 1 (".textual content") |
Outlined by an index into the part title string desk, pointing to a null-terminated ASCII string. |
| Kind | PROGBITS |
The loaded program will decide what these bytes imply. The information is opaque to the ELF file. |
| Flags | Allocatable + executable | Loaded into reminiscence throughout course of execution |
| Deal with | 0x4000F8 |
The place the info from this part will find yourself in reminiscence as soon as it’s loaded. Discover this is identical because the tackle of the executable program section. That is outlined as a result of the section is allocatable. |
| Offset | 0xF8 |
The place the info for this part resides inside this file |
| Dimension | 14 |
What number of bytes the part takes up on this file |
| Hyperlink | N/A | Hyperlinks to a different part header by index. The interpretation of this discipline is dependent upon the part sort. For this .textual content part, there is no such thing as a hyperlink as a result of this file represents a static binary. |
| Information | N/A | Any additional data, topic to interpretation based mostly on the part sort. No additional data for this part. |
| Deal with alignment | 0x1000 |
Any alignment constraint, in bytes, for the info on this part. The alignment right here is identical as that of the executable program section. |
| Entry dimension | N/A | For sections that include a desk of fixed-size entries (reminiscent of an emblem desk), this discipline states the scale of these entries in bytes. |
.shstrtab part: part title
The .shstrtab part is the part of the ELF file containing the names of the part headers, as null-terminated ASCII strings. This part is outlined by the next fields:
| Discipline | Worth | Notes |
|---|---|---|
| Title | 1 (".shstrtab") |
Outlined by an index into the part title string desk, pointing to a null-terminated ASCII string. |
| Kind | STRTAB |
A string desk. There could be different string tables within the file as effectively, although this one (by advantage of being referenced within the ELF header) is particularly the one used when trying up part names. |
| Flags | N/A | None of those fields apply to a string desk part. |
| Deal with | ||
| Offset | 0x106 |
The place the info for the string desk is within the file. |
| Dimension | 17 |
The variety of bytes the string desk occupies within the file. |
| Hyperlink | N/A | None of those fields apply to a string desk part. |
| Information | ||
| Deal with alignment | ||
| Entry dimension | N/A | Though this part is a desk, the entries usually are not fixed-width. |
.shstrtab part: part sort
The .shstrtab part is the part of the ELF file containing the names of the part headers, as null-terminated ASCII strings. This part is outlined by the next fields:
| Discipline | Worth | Notes |
|---|---|---|
| Title | 1 (".shstrtab") |
Outlined by an index into the part title string desk, pointing to a null-terminated ASCII string. |
| Kind | STRTAB |
A string desk. There could be different string tables within the file as effectively, although this one (by advantage of being referenced within the ELF header) is particularly the one used when trying up part names. |
| Flags | N/A | None of those fields apply to a string desk part. |
| Deal with | ||
| Offset | 0x106 |
The place the info for the string desk is within the file. |
| Dimension | 17 |
The variety of bytes the string desk occupies within the file. |
| Hyperlink | N/A | None of those fields apply to a string desk part. |
| Information | ||
| Deal with alignment | ||
| Entry dimension | N/A | Though this part is a desk, the entries usually are not fixed-width. |
.shstrtab part: non-applicable fields
The .shstrtab part is the part of the ELF file containing the names of the part headers, as null-terminated ASCII strings. This part is outlined by the next fields:
| Discipline | Worth | Notes |
|---|---|---|
| Title | 1 (".shstrtab") |
Outlined by an index into the part title string desk, pointing to a null-terminated ASCII string. |
| Kind | STRTAB |
A string desk. There could be different string tables within the file as effectively, although this one (by advantage of being referenced within the ELF header) is particularly the one used when trying up part names. |
| Flags | N/A | None of those fields apply to a string desk part. |
| Deal with | ||
| Offset | 0x106 |
The place the info for the string desk is within the file. |
| Dimension | 17 |
The variety of bytes the string desk occupies within the file. |
| Hyperlink | N/A | None of those fields apply to a string desk part. |
| Information | ||
| Deal with alignment | ||
| Entry dimension | N/A | Though this part is a desk, the entries usually are not fixed-width. |
.shstrtab part: part offset
The .shstrtab part is the part of the ELF file containing the names of the part headers, as null-terminated ASCII strings. This part is outlined by the next fields:
| Discipline | Worth | Notes |
|---|---|---|
| Title | 1 (".shstrtab") |
Outlined by an index into the part title string desk, pointing to a null-terminated ASCII string. |
| Kind | STRTAB |
A string desk. There could be different string tables within the file as effectively, although this one (by advantage of being referenced within the ELF header) is particularly the one used when trying up part names. |
| Flags | N/A | None of those fields apply to a string desk part. |
| Deal with | ||
| Offset | 0x106 |
The place the info for the string desk is within the file. |
| Dimension | 17 |
The variety of bytes the string desk occupies within the file. |
| Hyperlink | N/A | None of those fields apply to a string desk part. |
| Information | ||
| Deal with alignment | ||
| Entry dimension | N/A | Though this part is a desk, the entries usually are not fixed-width. |
.shstrtab part: part dimension
The .shstrtab part is the part of the ELF file containing the names of the part headers, as null-terminated ASCII strings. This part is outlined by the next fields:
| Discipline | Worth | Notes |
|---|---|---|
| Title | 1 (".shstrtab") |
Outlined by an index into the part title string desk, pointing to a null-terminated ASCII string. |
| Kind | STRTAB |
A string desk. There could be different string tables within the file as effectively, although this one (by advantage of being referenced within the ELF header) is particularly the one used when trying up part names. |
| Flags | N/A | None of those fields apply to a string desk part. |
| Deal with | ||
| Offset | 0x106 |
The place the info for the string desk is within the file. |
| Dimension | 17 |
The variety of bytes the string desk occupies within the file. |
| Hyperlink | N/A | None of those fields apply to a string desk part. |
| Information | ||
| Deal with alignment | ||
| Entry dimension | N/A | Though this part is a desk, the entries usually are not fixed-width. |
.shstrtab part: non-applicable fields
The .shstrtab part is the part of the ELF file containing the names of the part headers, as null-terminated ASCII strings. This part is outlined by the next fields:
| Discipline | Worth | Notes |
|---|---|---|
| Title | 1 (".shstrtab") |
Outlined by an index into the part title string desk, pointing to a null-terminated ASCII string. |
| Kind | STRTAB |
A string desk. There could be different string tables within the file as effectively, although this one (by advantage of being referenced within the ELF header) is particularly the one used when trying up part names. |
| Flags | N/A | None of those fields apply to a string desk part. |
| Deal with | ||
| Offset | 0x106 |
The place the info for the string desk is within the file. |
| Dimension | 17 |
The variety of bytes the string desk occupies within the file. |
| Hyperlink | N/A | None of those fields apply to a string desk part. |
| Information | ||
| Deal with alignment | ||
| Entry dimension | N/A | Though this part is a desk, the entries usually are not fixed-width. |
.shstrtab part: part entry dimension
The .shstrtab part is the part of the ELF file containing the names of the part headers, as null-terminated ASCII strings. This part is outlined by the next fields:
| Discipline | Worth | Notes |
|---|---|---|
| Title | 1 (".shstrtab") |
Outlined by an index into the part title string desk, pointing to a null-terminated ASCII string. |
| Kind | STRTAB |
A string desk. There could be different string tables within the file as effectively, although this one (by advantage of being referenced within the ELF header) is particularly the one used when trying up part names. |
| Flags | N/A | None of those fields apply to a string desk part. |
| Deal with | ||
| Offset | 0x106 |
The place the info for the string desk is within the file. |
| Dimension | 17 |
The variety of bytes the string desk occupies within the file. |
| Hyperlink | N/A | None of those fields apply to a string desk part. |
| Information | ||
| Deal with alignment | ||
| Entry dimension | N/A | Though this part is a desk, the entries usually are not fixed-width. |
Program header desk
Every program header describes some piece of data that is wanted to organize this system for execution. Sometimes, this might be one thing like a “program section” that can go someplace contained in the digital reminiscence area. In contrast to the sections referenced by the part header, this system segments are extra about what’s within the course of after it has been loaded into reminiscence, not what’s within the ELF file. That mentioned, the info that goes into reminiscence is likely to be current on this file, however typically, the main target is on the runtime, not the compile and hyperlink time.
Be aware: the order of the info in every program header is dependent upon whether or not the ELF file targets a 32-bit or a 64-bit structure. For instance, the section flags instantly follows the section sort for 64-bit architectures however comes later for 32-bit architectures. As a result of this file is configured to focus on a 64-bit structure, the bytes beneath will assume the corresponding format.
Phase sort
This section is a “loadable” section. This tells the system that N bytes from this file (at an outlined offset) might be loaded right into a reminiscence location (at one other outlined offset) occupying M bytes. If N is lower than M, then the remaining bytes in reminiscence might be initialized to zero.
On this file, we have set it up in order that N and M are equal.
Phase flags
Readable and executable, which is the usual for executable segments. Avoiding writes permits a degree of safety, the place it`s assured the code being executed won’t out of the blue change throughout execution. (Permitting self-modifying code or JIT compilation requires some additional thought.)
Offset in file
The offset, in bytes, the place the info for this section resides on this file. For this executable section, the info needs to be loaded from 0xF8, which is the place the .textual content part is positioned.
Digital reminiscence tackle
The digital reminiscence tackle the place this section will reside as soon as it’s loaded. Discover that this is identical tackle because the “entry level” outlined within the ELF header, as this section is the place the executable code will reside for the executable to leap to as soon as the method is began.
Bodily reminiscence tackle
The bodily reminiscence tackle the place this section will reside as soon as it’s loaded. Solely related for programs the place bodily addressing is related, so for many usages, this worth is irrelevant.
Phase dimension in file
The variety of bytes the section knowledge takes up on this file.
Phase dimension in reminiscence
The variety of bytes the section knowledge takes up in reminiscence after the info has been loaded.
Phase aligmnent
The alignment of the section, in bytes, for each the info on this file and the section within the digital reminiscence area after it has been loaded. The truth that the alignment applies to each is necessary, as it’s required that the offset within the file is the same as the digital reminiscence tackle, modulo the alignment. That is certainly the case, as 0x4000F8 == 0xF8 (modulo 0x1000).
Program code: .textual content part
The precise machine code that might be executed. Recall:
-
This code is referenced, as an offset into this file, as the info that might be loaded into the executable program section, as specified by the corresponding program header.
-
The code will get loaded into a selected a part of the digital reminiscence area, once more as specified by the identical program header.
-
Lastly, the ELF header tells the system to leap to that digital reminiscence tackle.
With the mix of those directives, the code on this part is precisely what will get executed when this program is run!
See an x86-64 opcode reference guide for extra data relating to how these opcodes correspond to particular directions.
Program code
This code makes the exit system name (quantity 60) with an argument of 42. Basically, this causes the method to return the standing code 42.
mov $60, %rax
mov $42, %edi
syscallProgram code
This code makes the exit system name (quantity 60) with an argument of 42. Basically, this causes the method to return the standing code 42.
mov $60, %rax
mov $42, %edi
syscallProgram code
This code makes the exit system name (quantity 60) with an argument of 42. Basically, this causes the method to return the standing code 42.
mov $60, %rax
mov $42, %edi
syscallPart title string desk
This part is a string desk, of which there could also be others within the file. This specific string desk is what’s used to search for names of the sections, and subsequently, these strings are referenced by the part header desk. Every entry of this desk is an ASCII, null-terminated string, with the very first entry within the desk being simply the null-terminator.
A reference into this desk is a zero-indexed byte offset into this part’s knowledge. For instance, to reference the primary non-empty string within the desk, the reference can be 1 for byte 1. By referencing into the center of one other string, it is potential to reuse widespread suffixes, as is finished with part names like .textual content and .rel.textual content. This optimization isn’t wanted for the minimal file, however is widespread in compiler-generated ELF information.
NULL
Simply the null terminator. That is required to be the zero byte by the ELF specification.
".textual content"
The title of the .textual content part.
".shstrtab"
The title of this part! Stands for section header string table.