By nike on Jun 05, 2007
elfdump -c /bin/lsshows
Section Header: sh_name: .interp sh_addr: 0x100f4 sh_flags: [ SHF_ALLOC ] sh_size: 0x11 sh_type: [ SHT_PROGBITS ] sh_offset: 0xf4 sh_entsize: 0 sh_link: 0 sh_info: 0 sh_addralign: 0x1 Section Header: sh_name: .hash sh_addr: 0x10108 sh_flags: [ SHF_ALLOC ] sh_size: 0x2c0 sh_type: [ SHT_HASH ] sh_offset: 0x108 sh_entsize: 0x4 sh_link: 3 sh_info: 0 sh_addralign: 0x4 .... Section Header: sh_name: .SUNW_signature sh_addr: 0 sh_flags: [ SHF_EXCLUDE ] sh_size: 0x10e sh_type: [ SHT_SUNW_SIGNATURE ] sh_offset: 0x6649 sh_entsize: 0 sh_link: 0 sh_info: 0 sh_addralign: 0x1And most tools manipulating with ELF work on the level of sections. But interestingly enough, ELF loader in the kernel doesn't really cares about ELF sections at all, instead it looks on so called "program headers".
elfdump -p /bin/ls shows
Program Header: p_vaddr: 0x10034 p_flags: [ PF_X PF_R ] p_paddr: 0 p_type: [ PT_PHDR ] p_filesz: 0xc0 p_memsz: 0xc0 p_offset: 0x34 p_align: 0 Program Header: p_vaddr: 0 p_flags: [ PF_R ] p_paddr: 0 p_type: [ PT_INTERP ] p_filesz: 0x11 p_memsz: 0 p_offset: 0xf4 p_align: 0 ... Program Header: p_vaddr: 0 p_flags: [ PF_W PF_R ] p_paddr: 0 p_type: [ PT_SUNWSTACK ] p_filesz: 0 p_memsz: 0 p_offset: 0 p_align: 0So essentially ELF files has two views: section view, defining what goes where in file and program view defining exact mapping of ELF data in process address space.
It has implications, such as one could attach dangling program header to ELF file, and while it not noticed by programs manipulating with ELF sections, it's still loaded by kernel into process' address space.