👹
Carlos's Tech Blog
  • 🧔ECUs
    • ZYNQ_Documents
      • [ZYNQ] 构建ZYNQ的BSP工程
      • [ZYNQ] 启动流程
      • [ZYNQ] Secure Boot Flow
      • [ZYNQ] Provisioning Guideline
      • [ZYNQ] Decrypting Partition by the Decrypt Agent Using PUF key
      • [ZYNQ] enabling the cryptsetup on ramdisk
      • [ZYNQ] Encrypt external files based on file system using PUF key
      • [ZYNQ] Loading an Encrypted Linux kernel at U-Boot with a KUP Key
      • [ZYNQ] cross-compile the cryptsetup on Xilinx ZYNQ aarch64 platform
      • [ZYNQ] Linux Linaro系统镜像制作SD卡启动
    • S32G_Documents
      • [S32G] Going through the s32g hard/soft platform
      • [S32G] S32g247's Secure Boot using HSE firmware
        • S32g2 HSE key config
        • How S32g verify secure boot image
        • S32g secure boot signature generation
        • How to download and build S32g Secure boot image
        • [S32G] OTA with Secure Boot
    • RT117x_Documents
      • [RT-117x]IMX RT1170 Provisioning Guideline
      • [RT-117x] Going through the MX-RT1170 hard/soft platform
      • [RT-117x] i.MX-RT1170's Secure Boot
        • [RT-117x]Signing image with the HSM (SignServer)
    • LS104x_Documents
      • [LS104x] bsp project
      • [LS104x] boot flow
      • [LS104x] secure boot
      • [LS104x] Application Note, Using the PKCS#11 in TCU platform
      • [LS104x] 使用ostree更新rootfs
      • [LS104x] ostree的移植
      • [LS104x] Starting with Yocto
      • [LS104x] 使用FIT的kernel格式和initramfs
    • IMX6/8_Documents
      • [IMX6] Defining A U-Boot Command
      • NXP IMX6 嵌入式板子一些笔记
      • NXP-imx6 initialization
    • Vehicle_Apps
      • [SecOC] Tree
        • [SecOC] SecOC Freshness and MAC Truncation
  • 😾TECH
    • Rust Arm OS
      • ARMv7m_Using_The_RUST_Cross_Compiler
    • ARM
      • ARM-v7-M
        • 01_ARMv7-M_处理器架构技术综述
        • 02_ARMv7-M_编程模型与模式
        • 03_ARMv7-M_存储系统结构
        • 04_ARMv7-M_异常处理及中断处理
      • ARM-v8-A
        • 02_ARMv8_基本概念
        • 03_ARMv8_指令集介绍_加载指令集和存储指令集
        • 04_ARMv8_指令集_运算指令集
        • 05_ARMv8_指令集_跳转_比较与返回指令
        • 06_ARMv8_指令集_一些重要的指令
        • 0X_ARMv8_指令集_基于汇编的UART驱动
        • 07_ARMv8_汇编器Using as
        • 08_ARMv8_链接器和链接脚本
        • 09_ARMv8_内嵌汇编(内联汇编)Inline assembly
        • 10_ARMv8_异常处理(一) - 入口与返回、栈选择、异常向量表
        • 11_ARMv8_异常处理(二)- Legacy 中断处理
        • 12_ARMv8_异常处理(三)- GICv1/v2中断处理
        • 13_ARMv8_内存管理(一)-内存管理要素
        • 14_ARMv8_内存管理(二)-ARM的MMU设计
        • 15_ARMv8_内存管理(三)-MMU恒等映射及Linux实现
        • 16_ARMv8_高速缓存(一)cache要素
        • 17_ARMv8_高速缓存(二)ARM cache设计
        • 18_ARMv8_高速缓存(三)多核与一致性要素
        • 19_ARMv8_TLB管理(Translation Lookaside buffer)
        • 20_ARMv8_barrier(一)流水线和一致性模型
        • 21_ARMv8_barrier(二)内存屏障案例
      • ARM Boot Flow
        • 01_Embedded_ARMv7/v8 non-secure Boot Flow
        • 02_Embedded_ARMv8 ATF Secure Boot Flow (BL1/BL2/BL31)
        • 03_Embedded_ARMv8 BL33 Uboot Booting Flow
      • ARM Compiler
        • Compiler optimization and the volatile keyword
      • ARM Development
        • 在MACBOOK上搭建ARMv8架构的ARM开发环境
        • Starting with JLink debugger or QEMU
    • Linux
      • Kernel
        • 0x01_LinuxKernel_内核的启动(一)之启动前准备
        • 0x02_LinuxKernel_内核的启动(二)SMP多核处理器启动过程分析
        • 0x21_LinuxKernel_内核活动(一)之系统调用
        • 0x22_LinuxKernel_内核活动(二)中断体系结构(中断上文)
        • 0x23_LinuxKernel_内核活动(三)中断体系结构(中断下文)
        • 0x24_LinuxKernel_进程(一)进程的管理(生命周期、进程表示)
        • 0x25_LinuxKernel_进程(二)进程的调度器的实现
        • 0x26_LinuxKernel_设备驱动(一)综述与文件系统关联
        • 0x27_LinuxKernel_设备驱动(二)字符设备操作
        • 0x28_LinuxKernel_设备驱动(三)块设备操作
        • 0x29_LinuxKernel_设备驱动(四)资源与总线系统
        • 0x30_LinuxKernel_设备驱动(五)模块
        • 0x31_LinuxKernel_内存管理(一)物理页面、伙伴系统和slab分配器
        • 0x32_LinuxKernel_内存管理(二)虚拟内存管理、缺页与调试工具
        • 0x33_LinuxKernel_同步管理_原子操作_内存屏障_锁机制等
        • 01_LinuxDebug_调试理论和基础综述
      • Userspace
        • Linux-用户空间-多线程与同步
        • Linux进程之间的通信-管道(上)
        • Linux进程之间的通信-管道(下)
        • Linux进程之间的通信-信号量(System V)
        • Linux进程之间的通信-内存共享(System V)
        • Linux进程之间的通信-消息队列(System V)
        • Linux应用调试(一)方法、技巧和工具 - 综述
        • Linux应用调试(二)工具之coredump
        • Linux应用调试(三)工具之Valgrind
        • Linux机制之内存池
        • Linux机制之对象管理和引用计数(kobject/ktype/kset)
        • Linux机制copy_{to, from}_user
        • Linux设备树 - DTS语法、节点、设备树解析等
        • Linux System : Managing Linux Services - inittab & init.d
        • Linux System : Managing Linux Services - initramfs
      • Kernel Examples
        • Linux Driver - GPIO键盘驱动开发记录_OMAPL138
        • 基于OMAPL138的Linux字符驱动_GPIO驱动AD9833(一)之miscdevice和ioctl
        • 基于OMAPL138的Linux字符驱动_GPIO驱动AD9833(二)之cdev与read、write
        • 基于OMAPL138的字符驱动_GPIO驱动AD9833(三)之中断申请IRQ
        • Linux内核调用SPI驱动_实现OLED显示功能
        • Linux内核调用I2C驱动_驱动嵌套驱动方法MPU6050
    • OPTEE
      • 01_OPTEE-OS_基础之(一)功能综述、简要介绍
      • 02_OPTEE-OS_基础之(二)TrustZone和ATF功能综述、简要介绍
      • 03_OPTEE-OS_系统集成之(一)编译、实例、在QEMU上执行
      • 05_OPTEE-OS_系统集成之(三)ATF启动过程
      • 06_OPTEE-OS_系统集成之(四)OPTEE镜像启动过程
      • 07_OPTEE-OS_系统集成之(五)REE侧上层软件
      • 08_OPTEE-OS_系统集成之(六)TEE的驱动
      • 09_OPTEE-OS_内核之(一)ARM核安全态和非安全态的切换
      • 10_OPTEE-OS_内核之(二)对安全监控模式的调用的处理
      • 11_OPTEE-OS_内核之(三)中断与异常的处理
      • 12_OPTEE-OS_内核之(四)对TA请求的处理
      • 13_OPTEE-OS_内核之(五)内存和cache管理
      • 14_OPTEE-OS_内核之(六)线程管理与并发
      • 15_OPTEE-OS_内核之(七)系统调用及IPC机制
      • 16_OPTEE-OS_应用之(一)TA镜像的签名和加载
      • 17_OPTEE-OS_应用之(二)密码学算法和安全存储
      • 18_OPTEE-OS_应用之(三)可信应用的开发
      • 19_OPTEE-OS_应用之(四)安全驱动开发
      • 20_OPTEE-OS_应用之(五)终端密钥在线下发系统
    • Binary
      • 01_ELF文件_目标文件格式
      • 02_ELF文件结构_浅析内部文件结构
      • 03_ELF文件_静态链接
      • 04_ELF文件_加载进程虚拟地址空间
      • 05_ELF文件_动态链接
      • 06_Linux的动态共享库
      • 07_ELF文件_堆和栈调用惯例以ARMv8为例
      • 08_ELF文件_运行库(入口、库、多线程)
      • 09_ELF文件_基于ARMv7的Linux系统调用原理
      • 10_ELF文件_ARM的镜像文件(.bin/.hex/.s19)
    • Build
      • 01_Script_makefile_summary
    • Rust
      • 02_SYS_RUST_文件IO
    • Security
      • Crypto
        • 1.0_Security_计算机安全概述及安全需求
        • 2.0_Security_随机数(伪随机数)
        • 3.0_Security_对称密钥算法加解密
        • 3.1_Security_对称密钥算法之AES
        • 3.2_Security_对称密钥算法之MAC(CMAC/HMAC)
        • 3.3_Security_对称密钥算法之AEAD
        • 8.0_Security_pkcs7(CMS)_embedded
        • 9.0_Security_pkcs11(HSM)_embedded
      • Tools
        • Openssl EVP to implement RSA and SM2 en/dec sign/verify
        • 基于Mac Silicon M1 的OpenSSL 编译
        • How to compile mbedtls library on Linux/Mac/Windows
    • Embedded
      • eMMC启动介质
  • 😃Design
    • Secure Boot
      • JY Secure Boot Desgin
    • FOTA
      • [FOTA] Module of ECUs' FOTA unit design
        • [FOTA] Tech key point: OSTree Deployment
        • [FOTA] Tech key point: repositories role for onboard
        • [FOTA] Tech key point: metadata management
        • [FOTA] Tech key point: ECU verifying and Decrpting
        • [FOTA] Tech key point: time server
      • [FOTA] Local-OTA for Embedded Linux System
    • Provisioning
      • [X-Shield] Module of the Embedded Boards initialization
    • Report
由 GitBook 提供支持
在本页
  • 08_ARMv8_链接器和链接脚本
  • 01 aarch64-none-elf-ld
  • 02 重定位
  • Ref
  1. TECH
  2. ARM
  3. ARM-v8-A

08_ARMv8_链接器和链接脚本

https://github.com/carloscn/blog/issues/20

08_ARMv8_链接器和链接脚本

我们在03_ELF文件_静态链接里面提到了对于一般性Linux的最终的ELF文件的内部结构,包含了各种段,然后相同的符号是如何进行链接的,怎么生成一个ELF文件的。在Linux里面,使用aarch64-linux-gnu-gcc可以说是一个比较high-level的编译器,里面有个默认的链接配置,而如果使用aarch64-none-elf-gcc这种baremental环境下的编译器,可能就要自己进行链接和写一些链接脚本。我们研究ARMv8的gcc、ld的编译算是对ELF_静态链接的一个扩展,来更熟悉链接这个过程,加深对于ELF文件的理解。

01 aarch64-none-elf-

链接器英文是Linker,用于把多个目标文件的代码段、数据段、符号表等链接到一起组合成为一个二进制文件的bin-utils工具。为什么叫LD?根据文献,LD的原名叫做,loaDer和Link eDitor,所以简写为LD。我们来研究一下ld的命令行:

1.1 cmd

ld -o output.bin /lib/crt0.o hello.o -lc

上面是把crt0.o和hello.o以及libc.a连接成output.bin,-lc的表示包含libc(这个我试了一下aarch64-编译器无论是linux的还是baremental的都并不支持这个选项,只有x86自身的gcc是支持的)

看一个比较复杂的例子,在benos里面的例子:

aarch64-linux-gnu-ld -T src/linker.ld -Map benos.map -o build/benos.elf build/printk_c.o build/irq_c.o build/string_c.o

这里就有几个比较常用的ld的command line的参数,ld的参数实在是太多了看着有点绝望,先暂时掌握以下几个,然后浏览一下文档大概有个印象:

选项
说明

-T

指令链接脚本

-Map

输出一个符号表

-o

输出的二进制文件

-b

执行目标代码输入文件的格式

-e

使用指定的符号作为程序的初试执行点 aarch64-none-elf-ld -o out.bin a.o b.o -e main

-l

执行库文件添加到要链接的文件清单中

-L

指定路径添加到搜索库的目录中

-S

忽略来自输出文件的调试器符号信息

-s

忽略来自输出文件的所有符号信息

-t

在处理输入文件时显示他们的名称

-Ttext

使用指定的地址作为代码段的起始点

-Tdata

使用指定的地址作为数据段的起始点

-Tbss

使用指定地址作为bss段的起始点

-Bstatic

只使用静态库

-Bdynamic

只是用动态库

-defsym

在输出文件中定义指定的全局符号

1.2 链接脚本

1.2.1 基础例子

-T参数指定ld的链接脚本,可以告诉链接器,最终生成的可执行文件需要按照工程师的意愿进行空间布局。

SECTIONS{
	. = 0x100000;				// . is location counter (lc)
	.text : { *(.text) }		// 所有的o文件的text段
	. = 0x800000;
	.data : { *(.data) }    // 所有o文件的data段
	.bss : { *(.bss) }
}

我们现在准备a.c和b.c文件,然后使用gcc -c的方式把两个文件编译成独立的.o文件,然后使用上面的链接脚本,把text段放在0x100000,并把data段放在0x800000。

$ aarch64-none-elf-ld -o out.bin a.o b.o -e main -T linker.ld

使用objdump来来查看elf文件结构

$ aarch64-none-elf-objdump -s -d out.bin

观察发现,.text已经被映射到0x100000上面,.data已经被映射到0x800000上面。我们对linker的脚本稍微做下修改,让a.o和b.o的text段在不同的位置,a.o的text段在0x100000,而b.o的text段在0x20000,使用ld进行链接,然后查看readelf的结果

SECTIONS{
	. = 0x100000;
	.text : { a.o(.text) }
	. = 0x200000;
	.text : { b.o(.text) }
	. = 0x800000;
	.data : { *(.data) }
    . = 0x900000;
	.bss : { *(.bss) }
}

对于输入文件我们还可以使用EXCLUDE_FILE的内置函数来排除一些文件,例如EXCLUDE_FILE (*CRETN.o )

$ aarch64-none-elf-ld -o out.bin a.o b.o -e main -T linker.ld

不使用objdump,使用readelf也可以拿到这个值:

aarch64-none-elf-readelf -s out.bin

看到两个.text段,一个是a.o的text,一个是b.o的text段。如果在linker脚本中不指定lc的位置,那么紧凑排列的。

1.2.2 指定入口

上面所有命令都是-e main指定程序入口的地址,在链接脚本中也可以指定使用ENTRY()内置函数。

ENTRY(main)
SECTIONS{
    . = 0x100000;
    .text : { a.o(.text) }
    . = 0x200000;
    .text : { b.o(.text) }
    . = 0x800000;
    .data : { *(.data) }
    . = 0x900000;
    .bss : { *(.bss) }
}

优先级:

  • -e指定入口地址

  • ENTRY内置函数

  • 特定符号 start

  • 使用代码段的起始段

  • 使用地址0

1.2.3 符号赋值与引用

我们在linker脚本里面定义了start_of_text标识符,然后在c语言文件里面使用extern char start_of_text[];就可以轻松访问到这个位置的地址。

ENTRY(main)
SECTIONS{
    . = 0x100000;
    start_of_text = .;
    .text : { a.o(.text) }
    end_of_text = .;
    . = 0x200000;
    .text : { b.o(.text) }
    . = 0x800000;
    .data : { *(.data) }
    . = 0x900000;
    .bss : { *(.bss) }
}

甚至还可以在这里面 + - * /的计算地址。

1.2.4 section指定格式

section [address] [(type)]:
	[AT(lma)]
	[ALIGN(section_align)]
	[constraint]
	{
		output-section-command
		output-section-comaand
		...
	} [>region] [AT>lma_region] [:phdr :phdr ...] [=fillexp]
名字
含义

section

段的名字,例如.text .data段

address

虚拟地址的名字

type

输出端的属性

lma

加载地址

ALIGN

对齐要求

output-section-command

描述输入端如何映射到输出段

region

特定的内存区域

phdr

特定的程序段

Note, 如果没有AT指定LMA的地址,那么LMA和VMA是一致的。在嵌入式系统中,经常存在加载地址和虚拟地址不同的情况,如将映像文件加载到开发板的闪存中(由LMA指定),而bootloader需要将闪存内的文件复制到SDRAM里面(由VMA指定)。

我们这里根据benos里面提示的,构建一个基于ROM的映像文件,设定VMA和LMA地址不一样,映像文件存储在ROM中,运行程序的时候需要把ROM的映像文件复制到RAM中。ROM对应LMA,RAM对应VMA。

SECTIONS {
    .text   0x1000 :
    {
        *(.text);
        _etext = .;
    }

    .mdata  0x2000 :
    AT ( ADDR (.text) + SIZEOF (.text) )
    {
        _data = .;
        *(.data)
        _edata = .;
    }

    .bss    0x3000:
    {
        _bstart = .;
        *(.bss)
        *(COMMON)
        _bend = .;
    }
}

在链接脚本里面.mdata的区域为.text的基地址加上.text的大小,所以能看见VMA还是保持原来的样子,但是LMA已经变为0x1060了。

aarch64-none-elf-objdump -h out.bin

这样我们需要把0x1060地址的内容加载到0x2000的位置。

extern char _etext, _data, _edata, _bstart, _bend;
char *src = &_etext;
char *dst = &_data;

while(dst < &_edata)
	*dst ++ = *src++;

1.2.5 内建函数

  • ABSOLUTE: 绝对值

    . = 0xb00000;
    my_offset1 = ABSOLUTE(0x100);				// 等于0x100
    my_offset2 = 0x100;									// 等于0xb00100
  • ADDR:返回虚拟地址

  • ALIGN: 声明下一个align对齐的地址

  • SIZEOF: 一个段的大小

02 重定位

现在就有个问题了,比如我们编译计算机的程序,如果elf文件都把运行地址定好了,那么就会存在一个问题,不同的机型有着不同的内存结构,而且不同的机器上面运行的app也不一样,我们elf文件中锁定的地址说不定已经被某个应用占用了,那么这个问题如何解决的呢?肯定有一个机制去管理这些地址,让这些地址可以根据自己机器的运行状况,使用内存大小做了一个相对化的处理。我们需要了解三个地址:

  • 加载地址:LMA,ARM64处理器上电复位后是从异常向量表开始读取第一条指令,所以通常这个地方是存放代码最开始的部分。

  • 运行地址:程序运行时的地址,可以叫做虚拟地址(线性地址)

  • 链接地址:在编译(汇编)之后,使用的相对地址,用于给链接器进行一些符号重定位和链接操作。LKA

  • 存储地址:存储地址和虚拟地址可能是等价的,如果开了MMU,程序在FLASH之类的这个地址和VMA会有不同。

  • 逻辑地址:CPU在没有开启重定位寄存器的时候,逻辑地址和物理地址一样。

  • 物理地址:也为内存地址寄存器地址。CPU单元看到的是逻辑地址,内存单元看到的是物理地址。

2.1 LMA=VMA=LKA

SECTIONS
{
	. = 0x80000,
	.text.boot : { *(.text.boot) }
	.text : { *(.text) }
	.rodata : { *(.rodata) }
	.data : { *(.data) }
	. = ALIGN(0x8);
	bss_begin = .;
	.bss : { *(.bss*) } 
	bss_end = .;
}

aarch64-none-elf-ld -o out.bin a.o b.o -T ben.ld -Map ben.map

输出ben.map查看地址映射:

$ cat ben.map

Memory Configuration

Name             Origin             Length             Attributes
*default*        0x0000000000000000 0xffffffffffffffff

Linker script and memory map

LOAD a.o
LOAD b.o
                0x0000000000080000                . = 0x80000

.text.boot
 *(.text.boot)

.text           0x0000000000080000       0x60
 *(.text)
 .text          0x0000000000080000       0x34 a.o
                0x0000000000080000                main
 .text          0x0000000000080034       0x2c b.o
                0x0000000000080034                b_func

.iplt           0x0000000000080060        0x0
 .iplt          0x0000000000080060        0x0 a.o

.rela.dyn       0x0000000000080060        0x0
 .rela.iplt     0x0000000000080060        0x0 a.o

.rodata
 *(.rodata)

.data           0x0000000000080060        0x4
 *(.data)
 .data          0x0000000000080060        0x0 a.o
 .data          0x0000000000080060        0x4 b.o
                0x0000000000080060                b_share

.igot.plt       0x0000000000080068        0x0
 .igot.plt      0x0000000000080068        0x0 a.o
                0x0000000000080068                . = ALIGN (0x8)
                0x0000000000080068                bss_begin = .

.bss            0x0000000000080068        0x8
 *(.bss*)
 .bss           0x0000000000080068        0x4 a.o
                0x0000000000080068                bsssss
 .bss           0x000000000008006c        0x4 b.o
                0x000000000008006c                bss_value
                0x0000000000080070                bss_end = .
OUTPUT(out.bin elf64-littleaarch64)
LOAD linker stubs

.comment        0x0000000000000000       0x57
 .comment       0x0000000000000000       0x57 a.o
                                         0x58 (size before relaxing)
 .comment       0x0000000000000057       0x58 b.o

2.2 LMA≠(LKA=VMA)

SECTIONS
{
	. = 0x80000,
   _stext_boot = .;
	.text.boot : { *(.text.boot) }
   _etext_boot = .;

	.text : AT(0x90000) { *(.text) }
   .rodata : { *(.rodata) }
	.data : { *(.data) }
	. = ALIGN(0x8);
	bss_begin = .;
	.bss : { *(.bss*) }
	bss_end = .;
}
Name             Origin             Length             Attributes
*default*        0x0000000000000000 0xffffffffffffffff

Linker script and memory map

LOAD a.o
LOAD b.o
                0x0000000000080000                . = 0x80000
                0x0000000000080000                _stext_boot = .

.text.boot
 *(.text.boot)
                0x0000000000080000                _etext_boot = .

.text           0x0000000000080000       0x60 load address 0x0000000000090000
 *(.text)
 .text          0x0000000000080000       0x34 a.o
                0x0000000000080000                main
 .text          0x0000000000080034       0x2c b.o
                0x0000000000080034                b_func

可以看到load地址已经和vma不一致了。load地址0x90000,而.text的VMA是0x80000,这种情况下如果程序想要启动,需要把代码段从加载地址复制到链接地址。

2.3 VMA≠LKA

我们实际的嵌入式设备有很多ROM和RAM的存储器,有这么多VMA、LMA、LKA之类的也是因为有不同的加载stage导致的。我们理解,首先代码有编译阶段->存储到嵌入式NorFlash或者NandFlash阶段->装载DDR阶段->装载SRAM阶段->CPU执行阶段

  • 编译阶段

    • LMA和VMA不一致:存储到ROM阶段的时候需要拷贝ROM地址LMA的数据到VMA

    • 不存在链接地址的概念,或者说LMA = LKA

  • 存储到ROM阶段

    • 和编译阶段没有任何区别

    • ROM代码通常包含两部分,一部分是正常功能的,一部分是拷贝内存部分。

  • 装载SRAM阶段

    • 假设SRAM地址在(0x00)

    • 会把前4K的部分load到SRAM中。运行地址和链接地址不一样,因为SRAM在0x00

    • 指令集这面使用位置无关代码,都是根据PC值的相对位置寻址。

  • 装载DDR阶段

    • 假设DDR地址在(0x4000000)

    • CPU上电复位后从0x0取指令,运行的4K后面第部分 load到DDR

    • 等执行到DDR这面的程序之后,运行地址和链接地址就一致了。

    • 这里使用位置有关代码和无关代码都可以。

B指令没办法实现在链接地址运行的程序,只能用LDR对PC寄存器修改值。后面MMU还会对这边进行比较深入的解析。

Ref

  1. Wikipedia - Linker (computing)

  2. 链接地址、运行地址、加载地址、存储地址

上一页07_ARMv8_汇编器Using as下一页09_ARMv8_内嵌汇编(内联汇编)Inline assembly

最后更新于1年前

😾
image-20220406112849492
image-20220406100042857
image-20220406095759022