ELF Segment	Purpose
`DYNAMIC`	For dynamic binaries, this segment hold dynamic linking information and is usually the same as `.dynamic` section in ELF's linking view. See paragraph below.
`GNU_EH_FRAME`	Frame unwind information (EH = Exception Handling). This segment is usually the same as `.eh_frame_hdr` section in ELF's linking view.
`GNU_RELRO`	This segment indicates the memory region which should be made Read-Only after relocation is done. This segment usually appears in a dynamic link library and it contains `.ctors`, `.dtors`, `.dynamic`, `.got` sections. See paragraph below.
`GNU_STACK`	The permission flag of this segment indicates whether the stack is executable or not. This segment does not have any content; it is just an indicator.
`INTERP`	For dynamic binaries, this holds the full pathname of runtime linker `ld.so` This segement is the same as `.interp` section in ELF's linking view.
`LOAD`	Loadable program segment. Only segments of this type are loaded into memory during execution.
`NOTE`	Auxiliary information. For core dumps, this segment contains the status of the process (when the core dump is created), such as the signal (the process received and caused it to dump core), pending & held signals, process ID, parent process ID, user ID, nice value, cumulative user & system time, values of registers (including the program counter!) For more info, see `struct elf_prstatus` and `struct elf_prpsinfo` in Linux kernel source file `include/linux/elfcore.h` and `struct user_regs_struct` in `arch/x86/include/asm/user_64.h`
`TLS`	Thread-Local Storage

DYNAMIC

For dynamic binaries, this segment hold dynamic linking information and is usually the same as .dynamic section in ELF's linking view. See paragraph below.

GNU_EH_FRAME

Frame unwind information (EH = Exception Handling). This segment is usually the same as .eh_frame_hdr section in ELF's linking view.

GNU_RELRO

This segment indicates the memory region which should be made Read-Only after relocation is done. This segment usually appears in a dynamic link library and it contains .ctors, .dtors, .dynamic, .got sections. See paragraph below.

GNU_STACK

The permission flag of this segment indicates whether the stack is executable or not. This segment does not have any content; it is just an indicator.

INTERP

For dynamic binaries, this holds the full pathname of runtime linker ld.so

This segement is the same as .interp section in ELF's linking view.

LOAD

Loadable program segment. Only segments of this type are loaded into memory during execution.

NOTE

Auxiliary information.

For core dumps, this segment contains the status of the process (when the core dump is created), such as the signal (the process received and caused it to dump core), pending & held signals, process ID, parent process ID, user ID, nice value, cumulative user & system time, values of registers (including the program counter!)

For more info, see struct elf_prstatus and struct elf_prpsinfo in Linux kernel source file include/linux/elfcore.h and struct user_regs_struct in arch/x86/include/asm/user_64.h

TLS

Thread-Local Storage

ELF Section	Purpose
`.bss`	Uninitialized global data ("Block Started by Symbol"). Depending on the compilers, uninitialized global variables could be stored in a nameness section called `COMMON` (named after Fortran 77's "common blocks".) To wit, consider the following code: `int globalVar; static int globalStaticVar; void dummy() { static int localStaticVar; }` Compile with `gcc -c`, then on x86_64, the resulting object file has the following structure: `$ objdump -t foo.o SYMBOL TABLE: .... 0000000000000000 l O .bss 0000000000000004 globalStaticVar 0000000000000004 l O .bss 0000000000000004 localStaticVar.1619 .... 0000000000000004 O COM 0000000000000004 globalVar` so only the file-scope and local-scope global variables are in the `.bss` section. If one wants `globalVar` to reside in the `.bss` section, use the `-fno-common` compiler command-line option. Using `-fno-common` is encouraged, as the following example shows: `$ cat foo.c int globalVar; $ cat bar.c double globalVar; int main(){} $ gcc foo.c bar.c` Not only there is no error message about redefinition of the same symbol in both source files (notice we did not use the `extern` keyword here), there is no complaint about their different data types and sizes either. However, if one uses `-fno-common`, the compiler will complain: /tmp/ccM71JR7.o:(.bss+0x0): multiple definition of `globalVar' /tmp/ccIbS5MO.o:(.bss+0x0): first defined here ld: Warning: size of symbol `globalVar' changed from 8 in /tmp/ccIbS5MO.o to 4 in /tmp/ccM71JR7.o
`.comment`	A series of NULL-terminated strings containing compiler information.
`.ctors`	Pointers to functions which are marked as `__attribute__ ((constructor))` as well as static C++ objects' constructors. They will be used by `__libc_global_ctors` function. See paragraphs below.
`.data`	Initialized data.
`.data.rel.ro`	Similar to `.data` section, but this section should be made Read-Only after relocation is done.
`.debug_XXX`	Debugging information (for the programs which are compiled with `-g` option) which is in the DWARF 2.0 format. See here for DWARF debugging format.
`.dtors`	Pointers to functions which are marked as `__attribute__ ((destructor))` as well as static C++ objects' destructors. See paragraphs below.
`.dynamic`	For dynamic binaries, this section holds dynamic linking information used by `ld.so`. See paragraphs below.
`.dynstr`	NULL-terminated strings of names of symbols in `.dynsym` section. One can use commands such as `readelf -p .dynstr a.out` to see these strings.
`.dynsym`	Runtime/Dynamic symbol table. For dynamic binaries, this section is the symbol table of globally visible symbols. For example, if a dynamic link library wants to export its symbols, these symbols will be stored here. On the other hand, if a dynamic executable binary uses symbols from a dynamic link library, then these symbols are stored here too. The symbol names (as NULL-terminated strings) are stored in `.dynstr` section.
`.eh_frame` `.eh_frame_hdr`	Frame unwind information (EH = Exception Handling). See here for details. To see the content of `.eh_frame` section, use `readelf --debug-dump=frames-interp a.out`
`.fini`	Code which will be executed when program exits normally. See paragraphs below.
`.fini_array`	Pointers to functions which will be executed when program exits normally. See paragraphs below.
`.GCC.command.line`	A series of NULL-terminated strings containing GCC command-line (that is used to compile the code) options. This feature is supported since GCC 4.5 and the program must be compiled with `-frecord-gcc-switches` option.
`.gnu.hash`	GNU's extension to hash table for symbols. See here for its structure and the hash algorithm. The link editor `ld` calls `bfd_elf_gnu_hash` in in GNU Binutil's source file `bfd/elf.c` to compute the hash value. The runtime linker `ld.so` calls `do_lookup_x` in `elf/dl-lookup.c` to do the symbol look-up. The hash computing function here is `dl_new_hash`.
`.gnu.linkonceXXX`	GNU's extension. It means only a single copy of the section will be used in linking. This is used to by g++. g++ will emit each template expansion in its own section. The symbols will be defined as weak, so that multiple definitions are permitted.
`.gnu.version`	Versions of symbols. See here, here, here, and here for details of symbol versioning.
`.gnu.version_d`	Version definitions of symbols.
`.gnu.version_r`	Version references (version needs) of symbols.
`.got`	For dynamic binaries, this Global Offset Table holds the addresses of variables which are relocated upon loading. See paragraphs below.
`.got.plt`	For dynamic binaries, this Global Offset Table holds the addresses of functions in dynamic libraries. They are used by trampoline code in `.plt` section. If `.got.plt` section is present, it contains at least three entries, which have special meanings. See paragraphs below.
`.hash`	Hash table for symbols. See here for its structure and the hash algorithm. The link editor `ld` calls `bfd_elf_hash` in in GNU Binutil's source file `bfd/elf.c` to compute the hash value. The runtime linker `ld.so` calls `do_lookup_x` in `elf/dl-lookup.c` to do the symbol look-up. The hash computing function here is `_dl_elf_hash`.
`.init`	Code which will be executed when program initializes. See paragraphs below.
`.init_array`	Pointers to functions which will be executed when program starts. See paragraphs below.
`.interp`	For dynamic binaries, this holds the full pathname of runtime linker `ld.so`
`.jcr`	Java class registration information. Like `.ctors` section, it contains a list of addresses which will be used by `_Jv_RegisterClasses` function in CRT (C Runtime) startup files (see `gcc/crtstuff.c` in GCC's source tree)
`.note.ABI-tag`	This Linux-specific section is structured as a note section in ELF specification. Its content is mandated here.
`.note.gnu.build-id`	A unique build ID. See here and here
`.note.GNU-stack`	See here
`.nvFatBinSegment`	This segment contains information of nVidia's CUDA fat binary container. Its format is described by `struct __cudaFatCudaBinaryRec` in `__cudaFatFormat.h`
`.plt`	For dynamic binaries, this Procedure Linkage Table holds the trampoline/linkage code. See paragraphs below.
`.preinit_array`	Similar to `.init_array` section. See paragraphs below.
`.rela.dyn`	Runtime/Dynamic relocation table. For dynamic binaries, this relocation table holds information of variables which must be relocated upon loading. Each entry in this table is a `struct Elf64_Rela` (see `/usr/include/elf.h`) which has only three members: `offset` (the variable's [usually position-independent] virtual memory address which holds the "patched" value during the relocation process) `info` (Index into `.dynsym` section and Relocation Type) `addend` See paragraphs below for details about runtime relocation.
`.rela.plt`	Runtime/Dynamic relocation table. This relocation table is similar to the one in `.rela.dyn` section; the difference is this one is for functions, not variables. The relocation type of entries in this table is `R_386_JMP_SLOT` or `R_X86_64_JUMP_SLOT` and the "offset" refers to memory addresses which are inside `.got.plt` section. Simply put, this table holds information to relocate entries in `.got.plt` section.
`.rel.text` `.rela.text`	Compile-time/Static relocation table. For programs compiled with `-c` option, this section provides information to the link editor `ld` where and how to "patch" executable code in `.text` section. The difference between `.rel.text` and `.rela.text` is entries in the former does not have `addend` member. (Compare `struct Elf64_Rel` with `struct Elf64_Rela` in `/usr/include/elf.h`) Instead, the addend is taken from the memory location described by `offset` member. Whether to use `.rel` or `.rela` is platform-dependent. For x86_32, it is `.rel` and for x86_64, `.rela`
`.rel.XXX` `.rela.XXX`	Compile-time/Static relocation table for other sections. For example, `.rela.init_array` is the relocation table for `.init_array` section.
`.rodata`	Read-only data.
`.shstrtab`	NULL-terminated strings of section names. One can use commands such as `readelf -p .shstrtab a.out` to see these strings.
`.strtab`	NULL-terminated strings of names of symbols in `.symtab` section. One can use commands such as `readelf -p .strtab a.out` to see these strings.
`.symtab`	Compile-time/Static symbol table. This is the main symbol table used in compile-time linking or runtime debugging. The symbol names (as NULL-terminated strings) are stored in `.strtab` section. Both `.symtab` and `.symtab` can be stripped away by the `strip` command.
`.tbss`	Similar to `.bss` section, but for Thread-Local data. See paragraphs below.
`.tdata`	Similar to `.data` section, but for Thread-Local data. See paragraphs below.
`.text`	User's executable code

.bss

Uninitialized global data ("Block Started by Symbol").

Depending on the compilers, uninitialized global variables could be stored in a nameness section called COMMON (named after Fortran 77's "common blocks".) To wit, consider the following code:

    int globalVar;
    static int globalStaticVar;
    void dummy() {
       static int localStaticVar;
    }

Compile with gcc -c, then on x86_64, the resulting object file has the following structure:

    $ objdump -t foo.o

    SYMBOL TABLE:
     ....
    0000000000000000 l     O .bss   0000000000000004 globalStaticVar
    0000000000000004 l     O .bss   0000000000000004 localStaticVar.1619
     ....
    0000000000000004       O *COM*  0000000000000004 globalVar

so only the file-scope and local-scope global variables are in the .bss section.

If one wants globalVar to reside in the .bss section, use the -fno-common compiler command-line option. Using -fno-common is encouraged, as the following example shows:

    $ cat foo.c
    int globalVar;
    $ cat bar.c
    double globalVar;
    int main(){}
    $ gcc foo.c bar.c

Not only there is no error message about redefinition of the same symbol in both source files (notice we did not use the extern keyword here), there is no complaint about their different data types and sizes either. However, if one uses -fno-common, the compiler will complain:

    /tmp/ccM71JR7.o:(.bss+0x0): multiple definition of `globalVar'
    /tmp/ccIbS5MO.o:(.bss+0x0): first defined here
    ld: Warning: size of symbol `globalVar' changed from 8 in /tmp/ccIbS5MO.o to 4 in /tmp/ccM71JR7.o

.comment

A series of NULL-terminated strings containing compiler information.

.ctors

Pointers to functions which are marked as __attribute__ ((constructor)) as well as static C++ objects' constructors. They will be used by __libc_global_ctors function.

See paragraphs below.

.data

Initialized data.

.data.rel.ro

Similar to .data section, but this section should be made Read-Only after relocation is done.

.debug_XXX

Debugging information (for the programs which are compiled with -g option) which is in the DWARF 2.0 format.

See here for DWARF debugging format.

.dtors

Pointers to functions which are marked as __attribute__ ((destructor)) as well as static C++ objects' destructors.

See paragraphs below.

.dynamic

For dynamic binaries, this section holds dynamic linking information used by ld.so. See paragraphs below.

.dynstr

NULL-terminated strings of names of symbols in .dynsym section.

One can use commands such as readelf -p .dynstr a.out to see these strings.

.dynsym

Runtime/Dynamic symbol table. For dynamic binaries, this section is the symbol table of globally visible symbols. For example, if a dynamic link library wants to export its symbols, these symbols will be stored here. On the other hand, if a dynamic executable binary uses symbols from a dynamic link library, then these symbols are stored here too.

The symbol names (as NULL-terminated strings) are stored in .dynstr section.

.eh_frame
.eh_frame_hdr

Frame unwind information (EH = Exception Handling).

See here for details.

To see the content of .eh_frame section, use

readelf --debug-dump=frames-interp a.out

.fini

Code which will be executed when program exits normally. See paragraphs below.

.fini_array

Pointers to functions which will be executed when program exits normally. See paragraphs below.

.GCC.command.line

A series of NULL-terminated strings containing GCC command-line (that is used to compile the code) options.

This feature is supported since GCC 4.5 and the program must be compiled with -frecord-gcc-switches option.

.gnu.hash

GNU's extension to hash table for symbols.

See here for its structure and the hash algorithm.

The link editor ld calls bfd_elf_gnu_hash in in GNU Binutil's source file bfd/elf.c to compute the hash value.

The runtime linker ld.so calls do_lookup_x in elf/dl-lookup.c to do the symbol look-up. The hash computing function here is dl_new_hash.

.gnu.linkonceXXX

GNU's extension. It means only a single copy of the section will be used in linking. This is used to by g++. g++ will emit each template expansion in its own section. The symbols will be defined as weak, so that multiple definitions are permitted.

.gnu.version

Versions of symbols.

See here, here, here, and here for details of symbol versioning.

.gnu.version_d

Version definitions of symbols.

.gnu.version_r

Version references (version needs) of symbols.

.got

For dynamic binaries, this Global Offset Table holds the addresses of variables which are relocated upon loading. See paragraphs below.

.got.plt

For dynamic binaries, this Global Offset Table holds the addresses of functions in dynamic libraries. They are used by trampoline code in .plt section. If .got.plt section is present, it contains at least three entries, which have special meanings. See paragraphs below.

.hash

Hash table for symbols.

See here for its structure and the hash algorithm.

The link editor ld calls bfd_elf_hash in in GNU Binutil's source file bfd/elf.c to compute the hash value.

The runtime linker ld.so calls do_lookup_x in elf/dl-lookup.c to do the symbol look-up. The hash computing function here is _dl_elf_hash.

.init

Code which will be executed when program initializes. See paragraphs below.

.init_array

Pointers to functions which will be executed when program starts. See paragraphs below.

.interp

For dynamic binaries, this holds the full pathname of runtime linker ld.so

.jcr

Java class registration information.

Like .ctors section, it contains a list of addresses which will be used by _Jv_RegisterClasses function in CRT (C Runtime) startup files (see gcc/crtstuff.c in GCC's source tree)

.note.ABI-tag

This Linux-specific section is structured as a note section in ELF specification. Its content is mandated here.

.note.gnu.build-id

A unique build ID. See here and here

.note.GNU-stack

See here

.nvFatBinSegment

This segment contains information of nVidia's CUDA fat binary container. Its format is described by struct __cudaFatCudaBinaryRec in __cudaFatFormat.h

.plt

For dynamic binaries, this Procedure Linkage Table holds the trampoline/linkage code. See paragraphs below.

.preinit_array

Similar to .init_array section. See paragraphs below.

.rela.dyn

Runtime/Dynamic relocation table.

For dynamic binaries, this relocation table holds information of variables which must be relocated upon loading. Each entry in this table is a struct Elf64_Rela (see /usr/include/elf.h) which has only three members:

offset (the variable's [usually position-independent] virtual memory address which holds the "patched" value during the relocation process)
info (Index into .dynsym section and Relocation Type)
addend

See paragraphs below for details about runtime relocation.

.rela.plt

Runtime/Dynamic relocation table.

This relocation table is similar to the one in .rela.dyn section; the difference is this one is for functions, not variables.

The relocation type of entries in this table is R_386_JMP_SLOT or R_X86_64_JUMP_SLOT and the "offset" refers to memory addresses which are inside .got.plt section.

Simply put, this table holds information to relocate entries in .got.plt section.

.rel.text
.rela.text

Compile-time/Static relocation table.

For programs compiled with -c option, this section provides information to the link editor ld where and how to "patch" executable code in .text section.

The difference between .rel.text and .rela.text is entries in the former does not have addend member. (Compare struct Elf64_Rel with struct Elf64_Rela in /usr/include/elf.h) Instead, the addend is taken from the memory location described by offset member.

Whether to use .rel or .rela is platform-dependent. For x86_32, it is .rel and for x86_64, .rela

.rel.XXX
.rela.XXX

Compile-time/Static relocation table for other sections. For example, .rela.init_array is the relocation table for .init_array section.

.rodata

Read-only data.

.shstrtab

NULL-terminated strings of section names.

One can use commands such as readelf -p .shstrtab a.out to see these strings.

.strtab

NULL-terminated strings of names of symbols in .symtab section.

One can use commands such as readelf -p .strtab a.out to see these strings.

.symtab

Compile-time/Static symbol table.

This is the main symbol table used in compile-time linking or runtime debugging.

The symbol names (as NULL-terminated strings) are stored in .strtab section.

Both .symtab and .symtab can be stripped away by the strip command.

.tbss

Similar to .bss section, but for Thread-Local data. See paragraphs below.

.tdata

Similar to .data section, but for Thread-Local data. See paragraphs below.

.text

User's executable code

: 4005f8: push rbp 4005f9: mov rbp,rsp 4005fc: mov esi,DWORD PTR [rip+0x1003de] # 5009e0 <__bss_start> 400602: mov edi,0x40070c 400607: mov eax,0x0 40060c: call 400528 400611: leave 400612: ret So the variable `foo` is indeed located in `bar`'s `.bss` section. Let's double check with `nm`: $ nm -n bar | grep 5009e0 00000000005009e0 A __bss_start 00000000005009e0 A _edata 00000000005009e0 B foo (Symbols such as `__bss_start` and `_edata` are defined by the default `ld` script; one can search them in the output of `ld -verbose` command.) The dynamic relocation table of `bar` is: Relocation section '.rela.dyn' at offset 0x490 contains 2 entries: Offset Info Type Sym. Value Sym. Name + Addend 000000500998 000c00000006 R_X86_64_GLOB_DAT 0000000000000000 __gmon_start__ + 0 0000005009e0 000700000005 R_X86_64_COPY 00000000005009e0 foo + 0 **Now what happens during runtime is this**: After `ld.so` loads all dependent dynamic libraries, it starts processing their relocations. When it sees `foo` of `libfoo.so`, it calls `RESOLVE_MAP` with r\_type = `R_X86_64_GLOB_DAT` to get the Base Address, which is 0, and Symbol Value, which is 5009e0. Next it sees `foo` of `libfoo.so` has `R_X86_64_GLOB_DAT` relocation type, so it calculates the new address as 5009e0 = 0 + 5009e0 + 0 (addend) and stores the result somewhere inside `.got` section. After `ld.so` has processed relocations of all dynamic libraries, it starts processing the relocation table of `bar`. When it sees `foo` of `bar`, it calls `RESOLVE_MAP` again, but with r\_type = `R_X86_64_COPY`. This time, the address returned is the runtime address of `foo` in `libfoo.so`'s `.data` section. As mentioned earlier, this address holds the initial value of `foo`. Next it sees `foo` of `bar` has `R_X86_64_COPY` relocation type, so it uses `memcpy` to copy data to 5009e0 (see the `Sym. Value` of `.rela.dyn` section of `bar` above) from the runtime address of `foo` in `libfoo.so`'s `.data` section (see Glibc source file [`sysdeps/x86_64/dl-machine.h`](https://web.archive.org/web/20201202024834/http://sourceware.org/git/?p=glibc.git;a=blob_plain;f=sysdeps/x86_64/dl-machine.h)) The above example also illustrates the difference between `.got` section and `.got.plt` section. For the runtime linker `ld.so`, all it knows is entries in `PLTREL` segment, i.e. `.rela.dyn` section, (which corresponds to `.got` section) must be resolved/relocated immediately, while entries in `JMPREL` segment, i.e. `.rela.plt` section, (which corresponds to `.got.plt` section) can use lazy binding. For x86\_64 architecture, the relocation is actually not needed for `R_X86_64_JUMP_SLOT` relocation types (albeit the symbol resolution is still needed) PIC or no PIC ------------- When building a dynamic library, we are told to **always** compile the code with `-fPIC` option. **What's the difference then** ? Consider the following simple code: #include int bar; void foo() { printf("%d\n",bar); } Compile the above code in 32-bit mode with and without `-fPIC`: $ gcc -shared -m32 foo.c -o nopic.so $ gcc -shared -m32 -fPIC foo.c -o pic.so (If you try to compile the above in 64-bit mode, GCC will stop and insist you should compile with `-fPIC` option, i.e. you are going to see error message such as `` relocation R_X86_64_PC32 against symbol `XXXYYY' can not be used when making a shared object; recompile with -fPIC ``) The sections and relocation tables of `nopic.so` and `pic.so` are shown at left and right hand side, respectively: Section Headers: Section Headers: [Nr] Name Type Addr [Nr] Name Type Addr [ 0] NULL 0000 [ 0] NULL 0000 ... ... [ 8] .init PROGBITS 02f8 [ 8] .init PROGBITS 02f0 [ 9] .plt PROGBITS 0310 [ 9] .plt PROGBITS 0308 [10] .text PROGBITS 0340 [10] .text PROGBITS 0350 [11] .fini PROGBITS 0488 [11] .fini PROGBITS 04a8 [12] .rodata PROGBITS 04a4 [12] .rodata PROGBITS 04c4 ... ... [17] .dynamic DYNAMIC 14c0 [17] .dynamic DYNAMIC 14e0 [18] .got PROGBITS 1590 [18] .got PROGBITS 15a8 [19] .got.plt PROGBITS 159c [19] .got.plt PROGBITS 15b8 [20] .data PROGBITS 15b0 [20] .data PROGBITS 15d0 ... ... Relocation section '.rel.dyn' at offset 0x2b0 Relocation section '.rel.dyn' at offset 0x2b0 contains 7 entries: contains 5 entries: Offset Info Type Sym.Value Sym. Name Offset Info Type Sym.Value Sym. Name 00000439 00000008 R_386_RELATIVE 000015d0 00000008 R_386_RELATIVE 000015b0 00000008 R_386_RELATIVE 000015a8 00000106 R_386_GLOB_DAT 000015dc bar 00000434 00000101 R_386_32 000015bc bar ... 00000445 00000602 R_386_PC32 00000000 printf ... Relocation section '.rel.plt' at offset 0x2e8: Relocation section '.rel.plt' at offset 0x2d8 contains 2 entries: contains 3 entries: Offset Info Type Sym.Value Sym. Name Offset Info Type Sym.Value Sym. Name 000015a8 00000207 R_386_JUMP_SLOT 00000000 __gmon_start__ 000015c4 00000207 R_386_JUMP_SLOT 00000000 __gmon_start__ 000015ac 00000a07 R_386_JUMP_SLOT 00000000 __cxa_finalize 000015c8 00000607 R_386_JUMP_SLOT 00000000 printf ... When we compile with `-fPIC` we can see the variable `bar` has the right relocation type (`R_386_GLOB_DAT`) and the relocation takes place in the right section (`.got`) The same for `printf`. Without `-fPIC`, the relocations of the format string "\\n", `bar` and `printf` all take place inside the `.text` section! But we know `.text` section is in a Read-Only `LOAD` segment, so what `ld.so` would do ? As expected, `ld.so` will make `.text` section writeable, patch the bytes, and make it Read-Only again. Since the relocation of both `bar` and `printf` are in `.rel.dyn`, their relocations are performed immediately (no lazy binding), so this approach is feasible. So how does `ld.so` handle `R_386_RELATIVE`, `R_386_32` and `R_386_PC32` relocation types ? Let's look at the disassembly: 0000042c : 42c: 55 push ebp 42d: 89 e5 mov ebp,esp 42f: 83 ec 18 sub esp,0x18 432: 8b 15 00 00 00 00 mov edx,DWORD PTR ds:0x0 <-- reference to bar 438: b8 a4 04 00 00 mov eax,0x4a4 <-- reference to "%d\n" format string in .rodata 43d: 89 54 24 04 mov DWORD PTR [esp+0x4],edx 441: 89 04 24 mov DWORD PTR [esp],eax 444: e8 fc ff ff ff call 445 <-- reference to printf 449: c9 leave 44a: c3 ret How would the 4 bytes starting at 445 (`R_386_PC32` type) be patched ? Suppose at runtime, our `nopic.so` is loaded into memory with base address 8000, and the 4 bytes to be patched are now at 8000 + 445 = 8445. Furthermore, suppose `ld.so` has determined the entry address of `printf` to be 10000, then `ld.so` calculates the **relative** offset as follows: 10000 - 8445 + fffffffc = 7bb7 (fffffffc is -4) so `ld.so` replaces `fc ff ff ff` with `b7 7b 00 00` To patch the 4 bytes starting at 434 (`R_386_32` type) is simpler. `ld.so` will simply overwrite the 4 bytes with the runtime **absolute** address of `bar`. To patch the 4 bytes starting at 439 (`R_386_RELATIVE` type) `ld.so` calculates the address as 10000 + 4a4 = 104a4 so `ld.so` replaces `a4 04 00 00` with `a4 04 01 00` Finally, what about the `R_386_RELATIVE` relocation at 15b0 ? 15b0 is the starting address of `.data` section, and the first 4 bytes of `.data` section stores its own address, 15b0. So it has to be relocated and patched as `115b0`. In conclusion, `R_386_RELATIVE` means "32-bit relative to base address", `R_386_PC32` means the "32-bit IP-relative offset" and `R_386_32` means the "32-bit absolute." Troubleshooting `ld.so` ----------------------- ### What is "error while loading shared libraries: requires glibc 2.5 or later dynamic linker" ? The cause of this error is the dynamic binary (or one of its dependent shared libraries) you want to run only has `.gnu.hash` section, but the `ld.so` on the target machine is too old to recognize `.gnu.hash`; it only recognizes the old-school `.hash` section. This usually happens when the dynamic binary in question is built using newer version of GCC. The solution is to recompile the code with either `-static` compiler command-line option (to create a static binary), or the following option: -Wl,--hash-style=both This tells the link editor `ld` to create both `.gnu.hash` and `.hash` sections. According to `ld` documentation [here](https://web.archive.org/web/20201202024834/http://sourceware.org/binutils/docs/ld/Options.html), the old-school `.hash` section is the default, but the compiler can override it. For example, the GCC (which is version 4.1.2) on RHEL (Red Hat Enterprise Linux) Server release 5.5 has this line: $ gcc -dumpspecs .... *link: %{!static:--eh-frame-hdr} %{!m32:-m elf_x86_64} %{m32:-m elf_i386} --hash-style=gnu %{shared:-shared} .... ... For more information, see [here](https://web.archive.org/web/20201202024834/http://crtags.blogspot.com/2010/11/elf-elf-elf-dont-do-it.html). ### What is "Floating point exception" ? The cause of this error is the same as the previous question. On certain systems, e.g. RHEL, the old version `ld.so` is [backported](https://web.archive.org/web/20201202024834/http://www.wikipedia.org/wiki/Backporting) to emit "error while loading shared libraries: requires glibc 2.5 or later dynamic linker", but this is not always the case, and you will see this error instead. ### What is ".../libc.so.6: version \`GLIBC\_2.4' not found " ? As the error message says, some of the symbols need Glibc version 2.4 or higher. This can also be seen by $ objdump -x foo | grep 'Version References' -A10 Version References: required from libc.so.6: 0x0d696914 0x00 03 GLIBC_2.4 0x09691a75 0x00 02 GLIBC_2.2.5 ... The fix is to recompile the code with `-static` compiler command-line option. ### What is "FATAL: kernel too old" ? Even if you recompile the code with `-static` compiler command-line option to avoid any dependency on the dynamic Glibc library, you could still encounter the error in question, and your code will exit with Segmentation Fault error. This kernel version check is done by `DL_SYSDEP_OSCHECK` macro in Glibc's [`sysdeps/unix/sysv/linux/dl-osinfo.h`](https://web.archive.org/web/20201202024834/http://sourceware.org/git/?p=glibc.git;a=blob_plain;f=sysdeps/unix/sysv/linux/dl-osinfo.h) It calls `_dl_discover_osversion` to get current kernel's version. To wit, run your code (suppose it is not stripped) inside gdb, (gdb) run Starting program: foo FATAL: kernel too old Program received signal SIGSEGV, Segmentation fault. 0x00000000004324a9 in ptmalloc_init () (gdb) call _dl_discover_osversion() $1 = 132617 (gdb) p/x $1 $2 = 0x20609 (gdb) Here `0x20609` means the current kernel version is 2.6.9. The fix (or hack) is to add the following function in your code: int _dl_discover_osversion() { return 0xffffff; } and compile your code with `-static` compiler command-line option. Exploring Glibc's `pthread_t` ----------------------------- When one creates a thread using the Pthread API, one will get a `pthread_t` object as a handle. In Glibc, `pthread_t` is actually a pointer pointing to a `pthread` struct, which is opaque. Its definition can be found in Glibc's source tree at [`nptl/descr.h`](https://web.archive.org/web/20201202024834/http://sourceware.org/git/?p=glibc.git;a=blob_plain;f=nptl/descr.h). The first member of `pthread` struct is yet another struct called `tcbhead_t` defined in system-dependent header files such as [`nptl/sysdeps/x86_64/tls.h`](https://web.archive.org/web/20201202024834/http://sourceware.org/git/?p=glibc.git;a=blob_plain;f=nptl/sysdeps/x86_64/tls.h). It holds TLS related information. It contains at least an integer member called `multiple_threads` which indicates if the process is running in multi-thread mode. The second member of `pthread` struct is also a struct called `list_t` defined in [`nptl/sysdeps/pthread/list.h`](https://web.archive.org/web/20201202024834/http://sourceware.org/git/?p=glibc.git;a=blob_plain;f=nptl/sysdeps/pthread/list.h). The third and fourth members of `pthread` struct are thread ID and thread group ID (both are of `pid_t` type). Other members of `pthread` struct which are of interest: `int cancelhandling` for cancellation information, `int flags` for thread attributes, `start_routine` for start position of the code to be executed for the thread, `void *arg` for the argument to `start_routine` `void *stackblock` and `size_t stackblock_size` for thread-specific stack information. Since `pthread` struct is opaque, how can one obtain the above information, or more precisely, how can one obtain the offsets of these members within the `pthread` struct ? We can use the known information and search for the memory region pointed by `pthread_t`, as in this [code snippet](https://web.archive.org/web/20201202024834/http://www.acsu.buffalo.edu/%7Echarngda/code/tcb.c).

ABI	Application binary interface
a.out	Assembler output file format
BSS	Block started by symbol. The uninitialized data segment containing statically-allocated variables.
COFF	Common object file format
DTV	Dynamic thread vector (for TLS)
DWARF	A standardized debugging data format
GD	Global Dynamic (dynamic TLS) One of the Thread-Local Storage access models.
GOT	Global offset table
IE	Initial Executable (static TLS with assigned offsets) One of the Thread-Local Storage access models.
LD	Local Dynamic (dynamic TLS of local symbols) One of the Thread-Local Storage access models.
LE	Local Executable (static TLS) One of the Thread-Local Storage access models.
Mach-O	Mach object file format
PC	Program counter. On x86, this is the same as IP (Instruction Pointer) register.
PE	Portable executable
PHT	Program header table
PIC	Position independent code
PIE	Position independent executable
PLT	Procedure linkage table
REL RELA	Relocation
RVA	Relative virtual address
SHF	Section header flag
SHT	Section header table
SO	Shared object (another name for dynamic link library)
VMA	Virtual memory area/address