名词

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. 「NOI2016」循环之美 解题报告

    「NOI2016」循环之美 对于小数\(\frac{a}{b}\),如果它在\(k\)进制下被统计,需要满足要求并且不重复. 不重复我们确保这个分数是最简分数即\((a,b)=1\) 满足要求需要满足 ...

  2. (转)OpenFire源码学习之四:openfire的启动流程

    转:http://blog.csdn.net/huwenfeng_2011/article/details/43413233 openfire启动 ServerStarter 启动流程图: 启动的总入 ...

  3. C++语言编程基础

    C++程序设计语言可以看作C语言的改进和升级,不仅完全兼容了C语言的语法和函数库,还引入了面向对象.运算符重载.多态性.数据流和模板等最新的编程思想.极大地保证了源代码的生产率.质量和可重用性.GNU ...

  4. error LNK2019: 无法解析的外部符号 _PhInitializePhLib,该符号在函数 _EnumHandle 中被引用

    编译时提示上面的错误,而确实应用了该函数的库文件,直接搜索lib文件内容,发送该函数的声明如下_PhInitializePhLib@0 说明函数的编译方式和库文件的编译方式不同,发现该工程的调用约定为 ...

  5. jeecg的$.dialog的一些参数

      jeecg表单弹出框采用的技术是lhgdialog 一.配置全局默认参数 (function(config){ config['extendDrag'] = true; // 注意,此配置参数只能 ...

  6. Mysql DBA

    1 mysqldump: Error 2020: Got packet bigger than 'max_allowed_packet' bytes when dumping table `tb_co ...

  7. kmalloc vs vmalloc

    kmalloc分配物理上连续的空间,可以不是整页大小的. vmalloc分配逻辑上连接的空间,可以不是物理上连接的.

  8. 1067 Sort with Swap(0, i) (25 分)

    Given any permutation of the numbers {0, 1, 2,..., N−1}, it is easy to sort them in increasing order ...

  9. 剑指offer——49礼物的最大价值

    题目描述 在一个m*n的棋盘的每一格都放有一个礼物,每个礼物都有一定的价值(价值大于0).你可以从棋盘的左上角开始拿格子里的礼物,并每次向左或者向下移动一格,知道到达棋盘的右下角.给定一个棋盘及其上面 ...

  10. python:异常处理及程序调试

    1.异常概述 在程序运行过程中,经常会遇到各种各样的错误.这些错误统称为“异常”,在这些一场中有的是由于开发者将关键词写错导致,这类错误产生的是SyntaxError.invalid syntax(无 ...