Segments in an executable program C

Question

I read about sections and segments. It seems you could display a mapping between sections and segments as shown below.

$ readelf -l test Elf file type is EXEC (Executable file) Entry point 0x8048330 There are 9 program headers, starting at offset 52 Program Headers: Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align PHDR 0x000034 0x08048034 0x08048034 0x00120 0x00120 RE 0x4 INTERP 0x000154 0x08048154 0x08048154 0x00013 0x00013 R 0x1 [Requesting program interpreter: /lib/ld-linux.so.2] LOAD 0x000000 0x08048000 0x08048000 0x0065c 0x0065c RE 0x1000 LOAD 0x000f14 0x08049f14 0x08049f14 0x00104 0x00110 RW 0x1000 DYNAMIC 0x000f28 0x08049f28 0x08049f28 0x000c8 0x000c8 RW 0x4 NOTE 0x000168 0x08048168 0x08048168 0x00044 0x00044 R 0x4 GNU_EH_FRAME 0x000564 0x08048564 0x08048564 0x00034 0x00034 R 0x4 GNU_STACK 0x000000 0x00000000 0x00000000 0x00000 0x00000 RW 0x4 GNU_RELRO 0x000f14 0x08049f14 0x08049f14 0x000ec 0x000ec R 0x1 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 .rel.dyn .rel.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 

My questions,

• I could not understand what the titles of the programs mean? How are they related to segments?
• The division into segment display is clear. But can anyone name him? I see only numbers. I defined the code seg (03), data seg (02) and stack (07).

Answer 1

To understand the readelf output, it helps you understand the ELF file format. Refer to this document.

As for understanding how to interpret the readelf output, this may help the link .

As for your question 2, this link describes the segments. In this document, search for "Various sections containing program and control information:" to find the area where segment names are described.

This document describes the segments as follows:

Various sections contain information about the program and management:

  .bss This section holds uninitialized data that contributes to the program memory image. By definition, the system initializes the data with zeros when the program begins to run. This section is of type SHT_NOBITS. The attribute types are SHF_ALLOC and SHF_WRITE. .comment This section holds version control information. This section is of type SHT_PROGBITS. No attribute types are used. .ctors This section holds initialized pointers to the C++ constructor functions. This section is of type SHT_PROGBITS. The attribute types are SHF_ALLOC and SHF_WRITE. .data This section holds initialized data that contribute to the program's memory image. This section is of type SHT_PROGBITS. The attribute types are SHF_ALLOC and SHF_WRITE. .data1 This section holds initialized data that contribute to the program's memory image. This section is of type SHT_PROGBITS. The attribute types are SHF_ALLOC and SHF_WRITE. .debug This section holds information for symbolic debugging. The contents are unspecified. This section is of type SHT_PROGBITS. No attribute types are used. .dtors This section holds initialized pointers to the C++ destructor functions. This section is of type SHT_PROGBITS. The attribute types are SHF_ALLOC and SHF_WRITE. .dynamic This section holds dynamic linking information. The section's attributes will include the SHF_ALLOC bit. Whether the SHF_WRITE bit is set is processor-specific. This section is of type SHT_DYNAMIC. See the attributes above. .dynstr This section holds strings needed for dynamic linking, most commonly the strings that represent the names associated with symbol table entries. This section is of type SHT_STRTAB. The attribute type used is SHF_ALLOC. .dynsym This section holds the dynamic linking symbol table. This section is of type SHT_DYNSYM. The attribute used is SHF_ALLOC. .fini This section holds executable instructions that contribute to the process termination code. When a program exits normally the system arranges to execute the code in this section. This section is of type SHT_PROGBITS. The attributes used are SHF_ALLOC and SHF_EXECINSTR. .gnu.version This section holds the version symbol table, an array of ElfN_Half elements. This section is of type SHT_GNU_versym. The attribute type used is SHF_ALLOC. .gnu.version_d This section holds the version symbol definitions, a table of ElfN_Verdef structures. This section is of type SHT_GNU_verdef. The attribute type used is SHF_ALLOC. .gnu.version_r This section holds the version symbol needed elements, a table of ElfN_Verneed structures. This section is of type SHT_GNU_versym. The attribute type used is SHF_ALLOC. .got This section holds the global offset table. This section is of type SHT_PROGBITS. The attributes are processor specific. .hash This section holds a symbol hash table. This section is of type SHT_HASH. The attribute used is SHF_ALLOC. .init This section holds executable instructions that contribute to the process initialization code. When a program starts to run the system arranges to execute the code in this section before calling the main program entry point. This section is of type SHT_PROGBITS. The attributes used are SHF_ALLOC and SHF_EXECINSTR. .interp This section holds the pathname of a program interpreter. If the file has a loadable segment that includes the section, the section's attributes will include the SHF_ALLOC bit. Otherwise, that bit will be off. This section is of type SHT_PROGBITS. .line This section holds line number information for symbolic debugging, which describes the correspondence between the program source and the machine code. The contents are unspecified. This section is of type SHT_PROGBITS. No attribute types are used. .note This section holds information in the "Note Section" format. This section is of type SHT_NOTE. No attribute types are used. OpenBSD native executables usually contain a .note.openbsd.ident section to identify themselves, for the kernel to bypass any compatibility ELF binary emulation tests when loading the file. .note.GNU-stack This section is used in Linux object files for declaring stack attributes. This section is of type SHT_PROGBITS. The only attribute used is SHF_EXECINSTR. This indicates to the GNU linker that the object file requires an executable stack. .plt This section holds the procedure linkage table. This section is of type SHT_PROGBITS. The attributes are processor specific. .relNAME This section holds relocation information as described below. If the file has a loadable segment that includes relocation, the section attributes will include the SHF_ALLOC bit. Otherwise the bit will be off. By convention, "NAME" is supplied by the section to which the relocations apply. Thus a relocation section for .text normally would have the name .rel.text. This section is of type SHT_REL. .relaNAME This section holds relocation information as described below. If the file has a loadable segment that includes relocation, the section attributes will include the SHF_ALLOC bit. Otherwise the bit will be off. By convention, "NAME" is supplied by the section to which the relocations apply. Thus a relocation section for .text normally would have the name .rela.text. This section is of type SHT_RELA. .rodata This section holds read-only data that typically contributes to a nonwritable segment in the process image. This section is of type SHT_PROGBITS. The attribute used is SHF_ALLOC. .rodata1 This section holds read-only data that typically contributes to a nonwritable segment in the process image. This section is of type SHT_PROGBITS. The attribute used is SHF_ALLOC. .shstrtab This section holds section names. This section is of type SHT_STRTAB. No attribute types are used. .strtab This section holds strings, most commonly the strings that represent the names associated with symbol table entries. If the file has a loadable segment that includes the symbol string table, the section attributes will include the SHF_ALLOC bit. Otherwise the bit will be off. This section is of type SHT_STRTAB. .symtab This section holds a symbol table. If the file has a loadable segment that includes the symbol table, the section attributes will include the SHF_ALLOC bit. Otherwise the bit will be off. This section is of type SHT_SYMTAB. .text This section holds the "text", or executable instructions, of a program. This section is of type SHT_PROGBITS. The attributes used are SHF_ALLOC and SHF_EXECINSTR. 

Answer 2

The program headers in the ELF binary describe how the binary should run. Interesting are the LOAD headers, which load part of a binary file to different places in memory. The binary can have an almost arbitrary number of LOAD headers, but usually the linker puts everything in read-only mode and executes them in one and all read / write to another. There are operating systems that will have a read-only LOAD header, read-write data, and read-only executable code for a bit more security.

Segments here mean only parts of a binary file loaded in different places in memory. So basically different LOAD headers.

Partitions are how data was organized during the binding. For various reasons, you want to improve your granularity, not just data / code. Some data is read-only, and in your example, ".rodata". The code is in ".text", the initialized data is in ".data", while the data in the variables that are reset to zero when the program starts are in ".bss".

The section “segment to segment” indicates which sections are in the segments (different LOAD headers). Thus, ".text" and ".rodata" are in the first LOAD header (third program header) and ".data" are in the second LOAD header (fourth program header).

The stack is what the operating system gives you to execute, and it is not described by the binary ELF code.