Dynamic linking on linux

program interpreter

The program interpreter¹ is declared in its own program header of type PT_INTERP. The then kernel² uses the p_offset and p_filesz fields to extract the path of the program interpreter. Linux also enforces that the last byte of the program interpreter is null, otherwise it will refuse to load the binary.

dynamic dependencies

The ELF spec states that programs that use dynamic linking must have a PT_DYNAMIC³ segment that corresponds to the .dynamic section (but the section doesn’t have to point to the same place⁴). Any good ELF parser should completely ignore the .dynamic section and only trust the PT_DYNAMIC segment. The dynamic segment contains a list of dynamic tags that start at p_vaddr⁵ into the binary.

typedef struct {
	Elf32_Sword	d_tag;
   	union {
   		Elf32_Word	d_val;
   		Elf32_Addr	d_ptr;
	} d_un;
} Elf32_Dyn;
 
typedef struct {
	Elf64_Sxword	d_tag;
   	union {
   		Elf64_Xword	d_val;
   		Elf64_Addr	d_ptr;
	} d_un;
} Elf64_Dyn;

The list of dynamic tags are terminated by a DT_NULL entry, e.g. a dynamic tag with the tag set to DT_NULL. The dynamic segment is completely ignored by the kernel and only matters to the program linker. Each dynamic dependency that the binary needs are stored as DT_NEEDED⁶ entries and the dynamic tag value is used to lookup the name of the dependency in the binary. The dynamic segment also stores other important information for loading the binary: string table address, relocation table address, string table address, etc. You should always trust the values in the dynamic segment instead of section addresses when parsing a binary, because this is what the linker⁷ does as well.