What's the difference of section and segment in ELF file format

From wiki Executable and Linkable Format:

> The segments contain information that is necessary for runtime execution of the file, while sections contain important data for linking and relocation. Any byte in the entire file can be owned by at most one section, and there can be orphan bytes which are not owned by any section.

But what is the difference between section and segment? In an executable ELF file, does a segment contain one or more sections?

> But what's difference between section and segment?

Exactly what you quoted: the segments contain information needed at runtime, while the sections contain information needed during linking.

> does a segment contain one or more sections?

A segment can contain 0 or more sections. Example:

readelf -l /bin/date

Elf file type is EXEC (Executable file)
Entry point 0x402000
There are 9 program headers, starting at offset 64

Program Headers:
  Type           Offset             VirtAddr           PhysAddr
                 FileSiz            MemSiz              Flags  Align
  PHDR           0x0000000000000040 0x0000000000400040 0x0000000000400040
                 0x00000000000001f8 0x00000000000001f8  R E    8
  INTERP         0x0000000000000238 0x0000000000400238 0x0000000000400238
                 0x000000000000001c 0x000000000000001c  R      1
      [Requesting program interpreter: /lib64/ld-linux-x86-64.so.2]
  LOAD           0x0000000000000000 0x0000000000400000 0x0000000000400000
                 0x000000000000d5ac 0x000000000000d5ac  R E    200000
  LOAD           0x000000000000de10 0x000000000060de10 0x000000000060de10
                 0x0000000000000440 0x0000000000000610  RW     200000
  DYNAMIC        0x000000000000de38 0x000000000060de38 0x000000000060de38
                 0x00000000000001a0 0x00000000000001a0  RW     8
  NOTE           0x0000000000000254 0x0000000000400254 0x0000000000400254
                 0x0000000000000044 0x0000000000000044  R      4
  GNU_EH_FRAME   0x000000000000c700 0x000000000040c700 0x000000000040c700
                 0x00000000000002a4 0x00000000000002a4  R      4
  GNU_STACK      0x0000000000000000 0x0000000000000000 0x0000000000000000
                 0x0000000000000000 0x0000000000000000  RW     8
  GNU_RELRO      0x000000000000de10 0x000000000060de10 0x000000000060de10
                 0x00000000000001f0 0x00000000000001f0  R      1

 Section to Segment mapping:
  Segment Sections...
   00     
   01     .interp 
   02     .interp .note.ABI-tag .note.gnu.build-id .gnu.hash .dynsym .dynstr .gnu.version .gnu.version_r .rela.dyn .rela.plt .init .plt .text .fini .rodata .eh_frame_hdr .eh_frame 
   03     .ctors .dtors .jcr .dynamic .got .got.plt .data .bss 
   04     .dynamic 
   05     .note.ABI-tag .note.gnu.build-id 
   06     .eh_frame_hdr 
   07     
   08     .ctors .dtors .jcr .dynamic .got 

Here, PHDR segment contains 0 sections, INTERP segment contains .interp section, and the first LOAD segment contains a whole bunch of sections.

Further reading with a nice illustration:

Section contains static for the linker, segment dynamic data for the OS

The quote is correct, but to actually understand it the difference, you should try to understand the fields of the section header and program header (segment) entries, and how they are be used by the linker (sections) and operating system (segment).

Particularly important informations are (besides lengths):

• section: tell the linker if a section is either:

  • raw data to be loaded into memory, e.g. .data, .text, etc.
  • or formatted metadata about other sections, that will be used by the linker, but disappear at runtime e.g. .symtab, .srttab, .rela.text

• segment: tells the operating system:

  • where should a segment be loaded into virtual memory
  • what permissions the segments have (read, write, execute). Remember that this can be efficiently enforced by the processor: https://stackoverflow.com/questions/18431261/how-does-x86-paging-work

I have written a tutorial that covers that in more detail at: http://www.cirosantilli.com/elf-hello-world/

Does a segment contain one or more sections?

Yes, and it is the linker that puts sections into segments.

In Binutils, how sections are put into segments by ld is determined by a text file called a linker script. Docs: https://sourceware.org/binutils/docs/ld/Scripts.html

You can get the default one with ld --verbose, and set a custom one with -T.

For example, my default Ubuntu 17.04 linker script contains:

  .text           :                                                                                                                                                             
  {                                                                                                                                                                             
    *(.text.unlikely .text.*_unlikely .text.unlikely.*)                                                                                                                         
    *(.text.exit .text.exit.*)                                                                                                                                                  
    *(.text.startup .text.startup.*)                                                                                                                                            
    *(.text.hot .text.hot.*)                                                                                                                                                    
    *(.text .stub .text.* .gnu.linkonce.t.*)                                                                                                                                                                                                                                                                                               
  } 

which tells the linker to put sections named .text.unlikely, .text.*_unlikely, .text.exit, etc. in the .text segment.

OS development is a case where custom scripts are useful, minimal example: https://github.com/cirosantilli/x86-bare-metal-examples/blob/d217b180be4220a0b4a453f31275d38e697a99e0/linker.ld

Once the executable is linked, it is only possible to know which section went to which segment if the linker stores the optional section header in the executable: https://stackoverflow.com/questions/23018496/where-is-the-section-to-segment-mapping-stored-in-elf-files

Please correct me if I'm wrong, as I wouldn't consider myself an expert on this topic, but according to my research some statements given in the answers/comments seem to be not fully accurate. To elaborate, I'll quote sentences and comment on them:

> Section contains static for the linker, segment dynamic data for the OS

According to this LWN article, the kernel only uses the segment header of type PT_INTERP, PT_LOAD and PT_GNU_STACK to load executables into memory. But there are other segment types, like PHDR, DYNAMIC, NOTE, GNU_EH_FRAME, GNU_PROPERTY, GNU_RELRO, which are ignored.

Afaiu, the GNU_RELRO segment is like a dummy segment; if it is present the loader uses this as a flag to make the relocation data read-only. But the loader is not part of the OS, at least for Linux.

As for the other segment types, I haven't found out what they are actually used for. They seem redundant to me, as there are corresponding sections which basically have the same or more information.

Thus, from my understanding that answer is only a simplified approximation of a more messy truth.

> sections are contained with segments

You can have ELF executables with no section header and relocatable (*.o) files usually do not have segment header. Furthermore, in the readelf output in the accepted answer one can see the .interp section in multiple segments. I do not see any containment restriction.

> the segments contain information needed at runtime, while the sections contain information needed during linking.

Again this seems like a simplification. The runtime loader (or "interpreter") also needs the sections for loading shared libraries, resolving symbols, doing relocations etc.

To conclude, while the given answers are probably reasonable general approximations, it apparently gets more complicated when looking at the details.