3

I have already read this post and I understand that segments contain runtime information and encapsulate sections, which contain linking information. But, I am still confused on why these terms are being used seemingly interchangeably in these two books.

"The Shellcoder's Handbook"

Next, information is loaded from the program’s executable file to the newly created address space. There are three types of segments: .text, .bss, and .data. The .text segment is mapped as read-only, whereas .data and .bss are writable. The .bss and .data segments are reserved for global variables. The .data segment contains static initialized data, and the .bss segment contains uninitialized data. The final segment, .text, holds the program instructions.

"Professional Assembly Language"

The text section is required in all assembly language programs. It is where the instruction codes are declared within the executable program. The data and bss sections are optional, but often used within a program. The data section declares data elements that are declared with an initial value. These data elements are used as variables within the assembly language program. The bss section declares data elements that are instantiated with a zero (or null) value. These data elements are most often used as buffer areas within the assembly language program.

chigger
  • 55
  • 5
  • In this context `section` is the correct term. The first book is just being sloppy. – Jester May 03 '20 at 23:21
  • Closely related: https://stackoverflow.com/a/14382477 – Employed Russian May 04 '20 at 00:39
  • @Jester: arguably segment is the correct term for grouping *types of* sections, and the sloppiness was applying section names to segments. e.g. `.text` and `.rodata` sections both get linked into the text segment. (Or used to; modern `ld` makes `.rodata` a separate ELF segment so it can be non-executable.) – Peter Cordes May 04 '20 at 01:31
  • @Jester: memory chunks `.text`, `.data` etc are defined in memory by **segment descriptors** and not by **section descriptors**, so I think that the term **segments** is more appropriate for memory blocks with different access rights. – vitsoft May 04 '20 at 11:21
  • _"There are three types of segments: .text, .bss, and .data."_ is just plain wrong. Those are not segment types. They are just standard names for some of the sections. – Jester May 04 '20 at 11:55

1 Answers1

7

In the context of ELF, they are two different related things.

  • Segments are described in the program header. Loosely, each segment describes a chunk of the file to be loaded into memory when an executable is run.

  • Sections are described in the section header. Loosely, each section describes a chunk of data relevant to the program.

So both sections and segments are chunks of the file, described as an offset and size (though in both cases the size may be 0, in which case the offset is ignored). Any given ELF file might have only segments, or only sections, or both segments and sections. In order to be executable it must have segments to load. In order to be linkable, it must have sections describing what is where.

Dynamically linked executable must have segments, but sections are still optional: There is a PT_DYNAMIC segment (see this) which indicates the content of the .dynamic section. In this way, the dynamic linker can still find the offset of the symbol table .dynsym.

In general, segments do not overlap each other and sections do not overlap each other, but sections may describe data that is part (or all) of a segment. That is not a strict requirement of the format, but it would be strange to violate. It would also be very strange for a section to describe data in two different segments. There are also (generally) sections that are not part of any segment.

Peter Cordes
  • 328,167
  • 45
  • 605
  • 847
Chris Dodd
  • 119,907
  • 13
  • 134
  • 226
  • 1
    "So a dynmaically linked executable will always have both." -- that part isn't quite correct:.run `strip a.out` and observe that there are no sections left. – Employed Russian May 04 '20 at 00:38
  • @EmployedRussian: only if the executable was statically linked -- if dynamic it will still have all the dynamic sections needed by the dynamic linker... – Chris Dodd May 04 '20 at 19:29
  • dynamic linker does _not_ need any sections, and does not use them. – Employed Russian May 04 '20 at 19:41
  • @EmployedRussian: then how does it find things to link? Those sections are still there in the executable after `strip` -- trying running objdump -h on a stripped elf binary and you'll see them. Or objdump -R to see the actual dynamic relocation records in the dynamic section (what the dynamic linker needs to fill in). – Chris Dodd May 04 '20 at 19:44
  • 3
    It turns out I am only partially correct: `strip` indeed leaves the sections (even though they are not needed), only `eu-strip --remove-sections` removes them. "How does it find things..." -- via the `PT_DYNAMIC` _segment_. See `readelf -d a.out`. – Employed Russian May 04 '20 at 20:42
  • is it right to say, segment is the instructions to execute, section is where the instructions are? – ArmadilloChubbz65 Jul 14 '22 at 09:49
  • @ArmadilloChubbz65: no, I would say that is completely misleading. Segments are how the kernel/CPU looks at the elf file and sections are how the linker looks at the elf file. – Chris Dodd Jul 14 '22 at 19:01
  • @ChrisDodd okay thanks, I wasnt trying to mislead anyone lol. I think I still have some reading to do – ArmadilloChubbz65 Jul 15 '22 at 13:02