名词

Extensible Linking Format(ELF)

3.1 The structure of an ARM ELF image

ARM ELF映像包含sections, regions, and segments,每个链接阶段都有不同的映像视图。

The structure of an image is defined by the:
  • Number of its constituent regions and output sections.
  • Positions in memory of these regions and sections when the image is loaded.
  • Positions in memory of these regions and sections when the image executes.
Each link stage has a different view of the image:
ELF object file view (linker input)
The ELF object file view comprises包含 input sections. The ELF object file can be:
  • A relocatable( 浮动的) file that holds code and data suitable for linking with other object files to create an executable or a shared object file.
  • A shared object file that holds code and data.
Linker view
The linker has two views for the address space of a program that become distinct in the presence of overlaid(覆盖层的存在), position-independent, and relocatable program fragments (code or data):
  • The load address of a program fragment is the target address that the linker expects an external agent such as a program loader, dynamic linker, or debugger to copy the fragment from the ELF file. This might not be the address at which the fragment executes.
  • The execution address of a program fragment is the target address where the linker expects the fragment to reside(属于,归于) whenever it participates(参加) in the execution of the program.
If a fragment is position-independent or relocatable, its execution address can vary during execution.
 
ELF image file view (linker output)
The ELF image file view comprises program segments and output sections:
  • A load region corresponds to a program segment.
  • An execution region contains one or more of the following output sections:
    • RO section.
    • RW section.
    • XO section.
    • ZI section.
One or more execution regions make up a load region. 

Note

With armlink, the maximum size of a program segment is 2GB.
When describing a memory view:
  • The term root region means a region that has the same load and execution addresses.
  • Load regions are equivalent to ELF segments.
The following figure shows the relationship between the views at each link stage:
Figure 3-1 Relationship between sections, regions, and segments

3.2 Input sections, output sections, regions, and program segments

An object or image file is constructed from a hierarchy of input sections, output sections, regions, and program segments.

Input section
An input section is an individual section from an input object file. It contains code, initialized data, or describes a fragment of memory that is not initialized or that must be set to zero before the image can execute. These properties are represented by attributes such as RO, RW, XO, and ZI. These attributes are used by armlink to group input sections into bigger building blocks called output sections and regions.
Output section
An output section is a group of input sections that have the same RO, RW, XO, or ZI attribute, and that are placed contiguously in memory by the linker. An output section has the same attributes as its constituent input sections. Within an output section, the input sections are sorted according to the section placement rules.
Region
A region contains up to four output sections depending on the contents and the number of sections with different attributes. By default, the output sections in a region are sorted according to their attributes. Any XO output section is first, followed by the RO output section, then the RW output section, and finally the ZI output section. A region typically maps onto a physical memory device, such as ROM, RAM, or peripheral. You can change the order of output sections using scatter-loading.
Program segment
A program segment corresponds to a load region and contains execution regions. Program segments hold information such as text and data.

3.3 Load view and execution view of an image

Image regions are placed in the system memory map at load time. The location of the regions in memory might change during execution.

Before you can execute the image, you might have to move some of its regions to their execution addresses and create the ZI output sections. For example, initialized RW data might have to be copied from its load address in ROM to its execution address in RAM.
The memory map of an image has the following distinct views:
Load view
Describes each image region and section in terms of the address where it is located when the image is loaded into memory, that is, the location before image execution starts.
Execution view
Describes each image region and section in terms of the address where it is located during image execution.
The following figure shows these views for an image without an execute-only (XO) section:
Figure 3-2 Load and execution memory maps for an image without an XO section

The following figure shows load and execution views for an image with an XO section:
Figure 3-3 Load and execution memory maps for an image with an XO section
 

The following table compares the load and execution views:

Table 3-1 Comparing load and execution views

Load Description Execution Description
Load address The address where a section or region is loaded into memory before the image containing it starts executing. The load address of a section or a non-root region can differ from its execution address Execution address The address where a section or region is located while the image containing it is being executed
Load region A load region describes the layout of a contiguous chunk of memory in load address space. Execution region An execution region describes the layout of a contiguous chunk of memory in execution address space.

3.6 Type 1 image structure, one load region and contiguous execution regions

A Type 1 image consists of a single load region in the load view and three execution regions placed contiguously in the memory map.

This approach is suitable for systems that load programs into RAM, for example, an OS bootloader or a desktop system. The following figure shows the load and execution view for a Type 1 image:
Figure 3-4 Simple Type 1 image

Use the following command for images of this type:
armlink --ro_base 0x8000

Note

0x8000 is the default address, so you do not have to specify --ro_base for the example.

Load view

The single load region consists of the RO and RW output sections, placed consecutively. The RO and RW execution regions are both root regions. The ZI output section does not exist at load time. It is created before execution, using the output section description in the image file.

Execution view

The three execution regions containing the RO, RW, and ZI output sections are arranged contiguously. The execution addresses of the RO and RW regions are the same as their load addresses, so nothing has to be moved from its load address to its execution address. However, the ZI execution region that contains the ZI output section is created at run-time.
Use armlink option --ro_base address to specify the load and execution address of the region containing the RO output. The default address is 0x8000.
Use the --zi_base command-line option to specify the base address of a ZI execution region.

Load view for images containing execute-only regions

For images that contain execute-only (XO) sections, the XO output section is placed at the address specified by --ro_base. The RO and RW output sections are placed consecutively and immediately after the XO section.

Execution view for images containing execute-only regions

For images that contain XO sections, the XO execution region is placed at the address specified by --ro_base. The RO, RW, and ZI execution regions are placed contiguously and immediately after the XO execution region.

3.7 Type 2 image structure, one load region and non-contiguous execution regions

A Type 2 image consists of a single load region, and three execution regions in execution view. The RW execution region is not contiguous with the RO execution region.

This approach is used, for example, for ROM-based embedded systems, where RW data is copied from ROM to RAM at startup. The following figure shows the load and execution view for a Type 2 image:
Figure 3-5 Simple Type 2 image

Use the following command for images of this type:
armlink --ro_base 0x0 --rw_base 0xA000

Load view

In the load view, the single load region consists of the RO and RW output sections placed consecutively, for example, in ROM. Here, the RO region is a root region, and the RW region is non-root. The ZI output section does not exist at load time. It is created at runtime.

Execution view

In the execution view, the first execution region contains the RO output section and the second execution region contains the RW and ZI output sections.
The execution address of the region containing the RO output section is the same as its load address, so the RO output section does not have to be moved. That is, it is a root region.
The execution address of the region containing the RW output section is different from its load address, so the RW output section is moved from its load address (from the single load region) to its execution address (into the second execution region). The ZI execution region, and its output section, is placed contiguously with the RW execution region.
Use armlink options --ro_base address to specify the load and execution address for the RO output section, and --rw_base address to specify the execution address of the RW output section. If you do not use the --ro_base option to specify the address, the default value of 0x8000 is used by armlink. For an embedded system, 0x0 is typical for the --ro_base value. If you do not use the --rw_base option to specify the address, the default is to place RW directly above RO (as in a Type 1 image).
Use the --zi_base command-line option to specify the base address of a ZI execution region.

Note

The execution region for the RW and ZI output sections cannot overlap any of the load regions.

Load view for images containing execute-only regions

For images that contain execute-only (XO) sections, the XO output section is placed at the address specified by --ro_base. The RO and RW output sections are placed consecutively and immediately after the XO section.

Execution view for images containing execute-only regions

For images that contain XO sections, the XO execution region is placed at the address specified by --ro_base. The RO execution region is placed contiguously and immediately after the XO execution region.
If you use --xo_base address, then the XO execution region is placed in a separate load region at the specified address.
 

3.8 Type 3 image structure, multiple load regions and non-contiguous execution regions

A Type 3 image is similar to a Type 2 image except that the single load region is split into multiple root load regions.

The following figure shows the load and execution view for a Type 3 image without execute-only (XO) code:
Figure 3-6 Simple Type 3 image

Use the following command for images of this type:
armlink --split --ro_base 0x8000 --rw_base 0xE000

Load view

In the load view, the first load region consists of the RO output section, and the second load region consists of the RW output section. The ZI output section does not exist at load time. It is created before execution, using the description of the output section contained in the image file.

Execution view

In the execution view, the first execution region contains the RO output section, the second execution region contains the RW output section, and the third execution region contains the ZI output section.
The execution address of the RO region is the same as its load address, so the contents of the RO output section do not have to be moved or copied from their load address to their execution address. Both RO and RW are root regions.
The execution address of the RW region is also the same as its load address, so the contents of the RW output section are not moved from their load address to their execution address. However, the ZI output section is created at run-time and is placed contiguously with the RW region.
Specify the load and execution address using the following linker options:
--ro_base address
Instructs armlink to set the load and execution address of the region containing the RO section at a four-byte aligned address, for example, the address of the first location in ROM. If you do not use the --ro_base option to specify the address, the default value of 0x8000 is used by armlink.
--rw_base address
Instructs armlink to set the execution address of the region containing the RW output section at a four-byte aligned address. If this option is used with --split, this specifies both the load and execution addresses of the RW region, for example, a root region.
--split
Splits the default single load region, that contains both the RO and RW output sections, into two root load regions:
  • One containing the RO output section.
  • One containing the RW output section.
You can then place them separately using --ro_base and --rw_base.

Load view for images containing XO sections

For images that contain XO sections, the XO output section is placed at the address specified by --ro_base. The RO and RW output sections are placed consecutively and immediately after the XO section.
If you use --split, then the one load region contains the XO and RO output sections, and the other contains the RW output section.

Execution view for images containing XO sections

For images that contain XO sections, the XO execution region is placed at the address specified by --ro_base. The RO execution region is placed contiguously and immediately after the XO execution region.
If you specify --split, then the XO and RO execution regions are placed in the first load region, and the RW and ZI execution regions are placed in the second load region.
If you specify --xo_base address, then the XO execution region is placed at the specified address in a separate load region from the RO execution region.
 

3.11 Section placement with the linker

The linker places input sections in a specific order by default.

By default, the linker places input sections in the following order within an execution region:
  1. By attribute as follows:
    1. Read-only code.
    2. Read-only data.
    3. Read-write code.
    4. Read-write data.
    5. Zero-initialized data.
  2. By input section name if they have the same attributes. Names are considered to be case-sensitive and are compared in alphabetical order using the ASCII collation sequence for characters.
  3. By a tie-breaker if they have the same attributes and section names. By default, it is the order that armlink processes the section. You can override this with the FIRST or LAST execution region attribute.

Note

The sorting order is unaffected by ordering of section selectors within execution regions.
These rules mean that the positions of input sections with identical attributes and names included from libraries depend on the order the linker processes objects. This can be difficult to predict when many libraries are present on the command line. The --tiebreaker=cmdline option uses a more predictable order based on the order the section appears on the command line.
The base address of each input section is determined by the sorting order defined by the linker, and is correctly aligned within the output section that contains it.
The linker produces one output section for each attribute present in the execution region:
  • One execute-only (XO) section if the execution region contains only XO sections.
  • One RO section if the execution region contains read-only code or data.
  • One RW section if the execution region contains read-write code or data.
  • One ZI section if the execution region contains Zero-initialized data.

Note

If an attempt is made to place data in an XO only execution region, then the linker generates an error.
XO sections lose the XO property if mixed with RO code in the same Execution region.
The XO and RO output sections can be protected at run-time on systems that have memory management hardware. RO and XO sections can be placed in ROM or Flash.
Alternative sorting orders are available with the --sort=algorithm command-line option. The linker might change the algorithm to minimize the amount of veneers generated if no algorithm is chosen.

Handling unassigned sections

The linker might not be able to place some input sections in any execution region. When this happens, the linker generates an error message. This might occur because your current scatter file does not permit all possible module select patterns and input section selectors. How you fix this depends on the importance of placing these sections correctly:
  • If the sections must be placed at specific locations, then modify your scatter file to include specific module selectors and input section selectors as required.
  • If the placement of the unassigned sections is not important, you can use one or more .ANY module selectors with optional input section selectors.

Examples

The following scatter file shows how the linker places sections:
 
LoadRegion 0x8000
{
ExecRegion1 0x0000 0x4000
{
*(sections)
*(moresections)
}
ExecRegion2 0x4000 0x2000
{
*(evenmoresections)
}
}
The order of execution regions within the load region is not altered by the linker.
 

3.12 Section placement with the FIRST and LAST attributes

You can make sure that a section is placed either first or last in its execution region. For example, you might want to make sure the section containing the vector table is placed first in the image.

To do this, use one of the following methods:
  • If you are not using scatter-loading, use the --first and --last linker command-line options to place input sections.
  • If you are using scatter-loading, use the attributes FIRST and LAST in the scatter file to mark the first and last input sections in an execution region if the placement order is important.
    However, FIRST and LAST must not violate the basic attribute sorting order. For example, FIRST RW is placed after any read-only code or read-only data.
 
 

3. Image Structure and Generation的更多相关文章

  1. GC那些事儿--Android内存优化第一弹

    引言 接App优化之内存优化(序), 作为App优化系列中内存优化的一个小部分. 由于内存相关知识比较生涩, 内存优化中使用到的相关工具, 也有很多专有名词. 对Java内存管理, GC, Andro ...

  2. Android内存优化5 了解java GC 垃圾回收机制3

    引言 接App优化之内存优化(序), 作为App优化系列中内存优化的一个小部分. 由于内存相关知识比较生涩, 内存优化中使用到的相关工具, 也有很多专有名词. 对Java内存管理, GC, Andro ...

  3. Apache Kafka: Next Generation Distributed Messaging System---reference

    Introduction Apache Kafka is a distributed publish-subscribe messaging system. It was originally dev ...

  4. JVM Specification 9th Edition (3) Chapter 2. The Structure of the Java Virtual Machine

    Chapter 2. The Structure of the Java Virtual Machine 内容列表 2.1. The class File Format (class文件的格式) 2. ...

  5. 1.2 the structure of a compiler

    Compiler 1.2 the structure  of a compiler Compiler : analysis and synthesis syntactically  语法上的 sema ...

  6. 《The challenge of realistic music generation: modelling raw audio at scale》论文阅读笔记

    The challenge of realistic music generation: modelling raw audio at scale 作者:Deep  mind三位大神 出处:NIPS ...

  7. 《SONG FROM PI: A MUSICALLY PLAUSIBLE NETWORK FOR POP MUSIC GENERATION》论文笔记

    出处:ICLR 2017 Motivation 提出一个通用的基于RNN的pop music生成模型,在层次结构中封装了先验乐理知识(prior knowledge about how pop mus ...

  8. 《MIDINET: A CONVOLUTIONAL GENERATIVE ADVERSARIAL NETWORK FOR SYMBOLIC-DOMAIN MUSIC GENERATION》论文阅读笔记

    出处 arXiv.org (引用量暂时只有3,too new)2017.7 SourceCode:https://github.com/RichardYang40148/MidiNet Abstrac ...

  9. 《MuseGAN: Multi-track Sequential Generative Adversarial Networks for Symbolic Music Generation and Accompaniment》论文阅读笔记

    出处:2018 AAAI SourceCode:https://github.com/salu133445/musegan abstract: (写得不错 值得借鉴)重点阐述了生成音乐和生成图片,视频 ...

随机推荐

  1. PHP ftp_chdir() 函数

    定义和用法 ftp_chdir() 函数改变 FTP 服务器上的当前目录为指定目录. 如果成功,该函数返回 TRUE.如果失败,则返回 FALSE 和一个警告. 语法 ftp_chdir(ftp_co ...

  2. Python_day01——变量

    变量 1.声明变量   name="钱成龙"  变量定义的规则: 变量名只能是 字母.数字或下划线的任意组合 变量名的第一个字符不能是数字 关键字不能声明为变量名 2.变量类型 整 ...

  3. [NOIP模拟测试11] 题解

    A.string 和河北的一道省选题很像.考场上写的暴力桶排,正解其实就是优化一下这个思路. 开线段树维护字符串中每个字母出现的次数.对于每条询问,区间查询.区间赋值维护即可. 另外,本题卡常严重,正 ...

  4. sublime 文件无法拖放

    sublime 文件无法拖放解决方法 https://github.com/emetio/pyv8-binaries 解决: 1. 去gihub下载 PyV8,连接地址:https://github. ...

  5. 剑指offer——38二叉搜索树与双向链表

    题目描述 输入一棵二叉搜索树,将该二叉搜索树转换成一个排序的双向链表.要求不能创建任何新的结点,只能调整树中结点指针的指向.   题解: 在搜索二义树中,左子节点的值总是小于父节点的值,右子节点的值总 ...

  6. Linux操作基础

    摘要 一.Linux操作系统概述 二.Linux操作系统安装 三.Linux文件系统及文件基础 四.Linux操作系统命令使用基础 五.Linux应用程序的安装与卸载基础 五.用户及进程 六.相关信息 ...

  7. C#WinForm 窗体单例模式 反射单例

    做了个mdi窗体 原以为指定一下MDIParent就可以了 没想到多次点击会出现多个窗体的现像 所以用到了单例模式 做法是这样的(学习出处:连接) 1.在子窗体声明一个子窗体类型的私有静态变量 并把子 ...

  8. 连接分析算法-HITS-算法

    转自http://blog.csdn.net/Androidlushangderen/article/details/43311943 参考资料:http://blog.csdn.net/hguisu ...

  9. STL 队列模板实现

    版权声明:本文为博主原创文章.未经博主同意不得转载. https://blog.csdn.net/u010016150/article/details/32715801   C++ Prime确实有点 ...

  10. spring boot jpa 多表关联 @OneToOne @OneToMany @ManyToOne@ManyToMany

    1.一对一关联 @OneToOne import lombok.Data; import javax.persistence.*; /** * @Author: GWL * @Description: ...