MAP File

https://warpproject.org/trac/wiki/howto/Linker_scripts_MAP_files

Description

• A MAP file is an output of the Linker.
• gives information about the symbols, addresses, allocated memory in the generated ELF file.
• It is extremely useful when trying to understand and debug linker issues related to code size.

 

Structure

• Archive member included to satisfy reference by file (symbol)
• Allocating common symbols
• Memory Configuration
• Linker script and memory map
• Cross Reference Table

 

Archive files

• An archive file is a file that is composed of one or more computer files along with metadata.
• Archive files are used to collect multiple data files together into a single file for easier portability and storage, or simply to compress files to use less storage space.
• Archive files often store directory structures, error detection and correction information, arbitrary comments, and sometimes use built-in encryption.
• This section details all of the members included from the various archive files in the system. This information is not especially useful, but lets you see all the system functions.

 

Allocating common symbols

• This section shows the names and sizes of global symbols (ie global variables) that have been allocated in the program.
• This is a good place to check that all global variables have expected sizes.
• A common mistake can be to unknowingly allocate a large global variable that consumes a lot of memory space.

Memory Configuration 

• The next section show the memory configuration.
• This should be the same as in the Linker Command File.

 

Linker script and memory map

• START GROUP & ENDGROUP
  • --start-group archives --end-group
  • The specified archives are searched repeatedly until no new undefined references are created. Normally, an archive is searched only once in the order that it is specified on the command line.
  • If a symbol in that archive is needed to resolve an undefined symbol referred to by an object in an archive that appears later on the command line, the linker would not be able to resolve that reference.
  • By grouping the archives, they all be searched repeatedly until all possible references are resolved.
  • Using this option has a significant performance cost. It is best to use it only when there are unavoidable circular references between two or more archives.

• Gives a wealth of information about where everything is mapped in the program.
• Each top level section, such as .text or .heap has both the starting address in the memory map as well as the size (in bytes) listed.
• Then each section is broken down into the individual object files and both the starting address and size is listed.
• Finally, each object file is broken down into the individual functions within the object file and the starting address for each function is listed.
• This allows you to understand which object files might contain large functions which are not necessary for your program execution.
• It can also give context when looking at pointer addresses within the program.
• MAP files are a great source of information when debugging your program.

• NOTE:
  • .text This section contains only executable instructions.
  • .sdata This section holds initialized short data that contribute to the program memory image.
  • .sbss This section holds uninitialized short data that contribute to the program memory image. By definition, the system initializes the data with zeros when the program begins to run.
  • .lit4 This section holds 4 byte read-only literals that contribute to the program memory image. Its purpose is to provide a list of unique 4-byte literals used by a program. Although this section has the SHF_WRITE attribute, it is not expected to be written. Placing this section in the data segment mandates the SHF_WRITE attribute.
  • .lit8 This section holds 8 byte read-only literals that contribute to the program memory image. Its purpose is to provide a list of unique 8-byte literals used by a program. Although this section has the SHF_WRITE attribute, it is not expected to be written. Placing this section in the data segment mandates the SHF_WRITE attribute.
  • .reginfo This section provides information on the program register usage to the system.
  • .liblist This section contains information on each of the libraries used at static link.
  • .conflict This section provides additional dynamic linking information about symbols in an executable file that conflict with symbols defined in the dynamic shared libraries with which the file is linked.
  • .gptab This section contains a global pointer table. The global pointer table is described in "Global Data Area" in this chapter. The section is named .gptab.sbss,.gptab.sdata, gptab.bss,or .gptab.data depending on which data section the particular .gptab refers.
  • .ucode This section name is reserved and the contents of this type of section are unspecified. The section contents can be ignored
  • .comment This section holds version control information.
  • .debug This section holds information for symbolic debugging. The contents are unspecified. All section names with the prefix .debug are reserved for future use.

• Function
  • LOADADDR(section)
    • Return the absolute LMA of the named section. This is normally the same as ADDR, but it may be different if the AT attribute is used in the output section definition
  • ASSERT(exp, message)
    • Ensure that exp is non-zero. If it is zero, then exit the linker with an error
    • code, and print message.

Cross Reference Table

• The format of the table is intentionally simple, so that it may be easily processed by a script if necessary.
• The symbols are printed out, sorted by name. For each symbol, a list of file names is given. If the symbol is defined, the first file listed is the location of the definition. The remaining files contain references to the symbol.
• all symbol in this table, seems no use for us.