ELF: Difference between revisions

{{File formats}}

 

A very versatile file format, it was later picked up by many other operating systems for use as both executable files and as shared library files. It does distinguish between TEXT, DATA and BSS.

 

Today, ELF is considered the standard format on Unix-alike systems. While it has some drawbacks (e.g., using up one of the scarce general purpose registers of the IA-32 when using position-independent code), it is well supported and documented.

==File Structure==

 

Note that depending on whether your file is a linkable or an executable file, the headers in the ELF file won't be the same:

process.o, result of gcc -c process.c $SOME_FLAGS

<pre>

C32/kernel/bin/.process.o

CONTENTS, READONLY

</pre>

The 'flags' will tell you what's actually available in the ELF file. Here, we have [[Symbol_Table|symbol tables]] and relocation: all that we need to link the file against another, but virtually no information about how to load the file in memory (even if that could be guessed). We don't have the program entry point, for instance, and we have a sections table rather than a program header.

{| {{wikitable}}

|-

| debugging symbols & similar information.

|}

/bin/bash, a real executable file

<pre>

/bin/bash: file format elf32-i386

40014000-40015000 rw-p 00013000 03:06 27304 /lib/ld-2.3.2.so

</pre>

We can recognize our 'code bits' and 'data bits', by stating that the second one should be loaded at 0x080bd*120* and that it starts in file at 0x00074*120*, we actually preserved page-to-disk blocks mapping (e.g. if page 0x80bc000 is missing, just fetch file blocks from 0x75000). That means, however, that a part of the code is mapped twice, but with different permissions. I suggest you do give them different physical pages too if you don't want to end up with modifiable code.

==Loading ELF Binaries==

The ELF header contains all of the relevant information required to load an ELF executable. The format of this header is described in the [http://www.skyfree.org/linux/references/ELF_Format.pdf ELF Specification]. The most relevant sections for this purpose are 1.1 to 1.4 and 2.1 to 2.7. Instructions on loading an executable are contained within section 2.7.

 

The following is a rough outline of the steps that an ELF executable loader must perform:

* Verify that the file starts with the ELF magic number (4 bytes) as described in figure 1-4 (and subsequent table) on page 11 in the ELF specification.

* Read the ELF Header. The ELF header is always located at the very beginning of an ELF file. The ELF header contains information about how the rest of the file is laid out. An executable loader is only concerned with the program headers.

 

==Relocation==

Relocation becomes handy when you need to load, for example, modules or drivers. It's possible to use the "-r" option to ld to permit you to have multiple object files linked into one big one, which means easier coding and faster testing.

 

# Go through all sections resolving external references against the kernel symbol table

# If all succeeded, you can use the "e_entry" field of the header as the offset from the load address to call the entry point (if one was specified), or do a symbol lookup, or just return a success error code.

Once you can relocate ELF objects you'll be able to have drivers loaded when needed instead of at startup - which is always a Good Thing (tm).

== Tables ==

{| {{wikitable}}

|-

| 6

| ELF header version

| 7

| 7

| 16-17

| 16-17

|-

| 18-19

| 20-23

| 20-23

| 24-27

| 24-31

|-

| 28-31

| 32-39

|-

| 32-35

| 40-47

|-

| 36-39

| 40-41

| 52-53

|-

| 42-43

| 50-51

| 62-63

|}

The flags entry can probably be ignored for x86 ELFs, as no flags are actually defined.

 

|-

| No Specific

|-

| [[:Category:Sparc | Sparc]]

|-

| '''[[x86]]'''

|-

| [[:Category:MIPS | MIPS]]

|-

| [[PowerPC]]

|}

The most common architectures are in bold.

=== Program header ===

This is an array of N (given in the main header) entries in the following format. Make sure to use the correct version depending on whether the file is 32 bit or 64 bit as the tables are quite different.

|-

| 12-15

|-

| 16-19

|-

| 20-23

|-

| 24-27

|-

| 28-31

|}

64 bit version:

{| {{wikitable}}

|-

| 24-31

|-

| 32-39

|-

| 40-47

|-

| 48-55

|}

 

Flags: 1 = executable, 2 = writable, 4 = readable.

=== Dynamic Linking ===

{{Main|Dynamic Linker}}

Dynamic Linking is when the OS gives a program shared libraries if it needs them. Meaning, the libraries are found in the system and then "bind" to the program that needs them while the program is running, versus static linking, which links the libraries '''before''' the program is run. The main advantages are that programs take up less memory, and are smaller in file size. The main disadvantage, however, is that the program becomes less portable because the program depends on many different shared libraries.

 

In order to implement this, you need to have proper scheduling in place, a library, and a program to use that library.

You can create a library with GCC:

<pre>

myos-gcc -c -fPIC -o oneobject.o oneobject.c

myos-gcc -shared -fPIC -Wl,-soname,nameofmylib oneobject.o anotherobject.o -o mylib.so

</pre>

This library should be treated as a file, which is loaded when the OS detects its attempted usage. You will need to implement this "[[Dynamic Linker]]" into a certain classification of code such as in your memory management or your task management section. When the ELF program is run, the system should attach the shared object data to a malloc() region of memory, where the function calls to the libraries redirect to that malloc() region of memory. Once the program is finished, the region can be given up back to the OS with a call to free().

 

That should be a good starting point to writing a dynamic linker.

== See Also ==

=== Articles ===

* [[Modular Kernel]]

* [[DWARF]]

=== External Links ===

* [http://www.skyfree.org/linux/references/ELF_Format.pdf The ELF file format] in detail

* [http://www.sco.com/developers/gabi/latest/contents.html System V ABI] about ELF

* [http://www.linuxfoundation.org/en/Specifications LSB specifications]<br />See (generic or platform-specific) 'Core' specifications for additional ELF information.

* [http://www.x86-64.org/documentation/abi.pdf x86-64 ABI] Documented x86-64 specific extensions with ELF64.

[[Category:ABI]]

[[Category:Executable Formats]]