可执行C程序中的段

我正在阅读有关章节和细分。 似乎你可以列出部分和之间的映射如下。

$ 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 

我的问题,

  1. 我不明白什么程序标题的意思? 它们如何与细分市场相关联?
  2. 分段映射部分是清楚的。 但是有人能说出来吗? 我只看到数字。 我确定了代码seg(03),data seg(02)和stack(07)。

Solutions Collecting From Web of "可执行C程序中的段"

要理解readelf的输出,将有助于您理解ELF文件的格式。 请参考这个文件。

至于理解如何解释readelf的输出这个链接可能会有所帮助。

至于你的问题2, 这个链接描述的部分。 在该文件中搜索“各个部分保存程序和控制信息:”以找到描述段名称的区域。

该文件描述了以下部分:

各个部分保存程序和控制信息:

  .bss This section holds uninitialized data that contributes to the program's 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's 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's 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's 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's 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. 

ELF二进制文件中的程序头文件描述了二进制文件应该如何运行。 有趣的部分是LOAD头文件,它将部分二进制文件加载到内存中的不同位置。 在一个二进制文件中,可能会有几乎任意数量的LOAD头文件,但通常链接器将所有只读和可执行文件放到一个文件夹中,所有内容都可以读/写。 有操作系统将具有只读数据LOAD标头,读写数据和只读可执行代码,以提高安全性。

这里的段只是指在内存中不同位置加载的二进制文件的一部分。 所以基本上是不同的LOAD头。

部分是数据在链接过程中的组织方式。 出于各种原因,您希望具有比数据/代码更好的粒度组织。 有些数据是只读的,在您的示例中将其放在“.rodata”中。 代码在“.text”中,初始化数据在“.data”中,而在程序启动时置零的变量中的数据在“.bss”中。

“分段映射部分”告诉你哪些部分在哪个段(不同的LOAD头部)。 所以“.text”和“.rodata”在第一个LOAD头(第三个程序头)中,“.data”在第二个LOAD头(第四个程序头)中。

这个堆栈是操作系统给你执行的东西,它不是由ELF二进制文件描述的。