segments within a executable C program

后端 未结 2 1411
傲寒
傲寒 2020-12-29 11:20

I was reading about sections and segments. Seems you could list the mapping between sections and segments as below.

$ readelf -l test

Elf file type is EXEC          


        
相关标签:
2条回答
  • 2020-12-29 11:56

    To understand the output of readelf it will help for you to understand the format of an ELF file. Please reference this document.

    As far as understanding how to interpret the output of readelf this link may be of help.

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

    That document describes the segments as follows:

    Various sections hold program and control information:

       .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.
    
    0 讨论(0)
  • 2020-12-29 11:56

    Program headers in an ELF binary describe how the binary should be run. The interesting parts are the LOAD headers which load part of the binary into different places in memory. There could be almost arbitrary number of LOAD headers in a binary, but usually the linker puts everything read-only and executable into one and everything read/write into another. There are operating systems which will have read-only data LOAD header, read-write data and read-only executable code for slightly increased security.

    Segments here just mean parts of the binary loaded in different places in memory. So basically the different LOAD headers.

    Sections is how the data was organized during linking. For various reasons you want to have better granularity organizing things than just data/code. Some data is read-only, it's put in ".rodata" in your example. The code is in ".text", initialized data is in ".data" while data in variables that are zeroed on program start are in ".bss".

    The "section to segment mapping" tells you which sections are in which segments (different LOAD headers). So ".text" and ".rodata" are in the first LOAD header (the third program header) and ".data" is in the second LOAD header (fourth program header).

    The stack is something that the operating system gives you on execution and it's not described by an ELF binary.

    0 讨论(0)
提交回复
热议问题