编译器是如何将芯片执行的第一个指令放到芯片起始地址的？
芯片上电后，会自动跳到第一需要执行的指令，那么编译器和链接器是做了哪些工作才让第一条指令被放在了正确的地方，以arm为例，uboot编译后为何能确保reset被放在了起始地址呢？
本人8年嵌入式Linux BSP开发经验，关于U-Boot的开发经验如下：
·平台开发：涉及ARM32/64、MIPS架构，MTK、海思等不下5个厂商U-Boot的BSP开发
·版本升级：将某平台的低版本U-boot升级至最新u-boot-2022.01版本
·架构设计：将业务代码从U-Boot中剥离，灵活适配不同U-boot版本、所有产品不同平台不同架构的不同单板
所以，相信有资格回答这个问题。
本文8000多字，掏心带你深入理解背后的原理，需要你耐心往下看。除了问题本身，你还将收获：
·什么是链接脚本，U-Boot下的链接脚本长什么样？
·U-Boot编译时是怎么链接的？
·U-Boot下这么多start.s，当前设备跑的到底是哪一个？
正文
这个问题往深了说就涉及到了编译原理。
在计算机世界中，其实每一次链接过程都是由链接脚本控制的。那么什么是链接脚本呢？简单说就是由链接器命令语言书写的，给链接器看的，主要的目的是描述输入文件中的段（如text段、data段、bss段等）如何在输出文件中组装，并控制输出文件的存储布局。
那么上面提到的链接器、链接脚本、输入文件、输出文件分别是指什么呢？
读万卷书，不如走一步路。动动手指，编译一下U-Boot就知道了，如果你还不清楚怎么编译或者没有环境的话，建议你参考我的文章搭建一个：
闪光吧Linux：走进嵌入式Linux大门的第二步——构建最新u-boot学习环境9赞同  · 0评论文章
下面是编译结果，截取重点如下：
$ make CROSS_COMPILE=aarch64-linux-gnu- V=1
....
aarch64-linux-gnu-ld.bfd -pie --gc-sections -Bstatic --no-dynamic-linker -z notext --build-id=none -Ttext 0x00000000 -o u-boot -T u-boot.lds arch/arm/cpu/armv8/start.o --whole-archive arch/arm/cpu/built-in.o arch/arm/cpu/armv8/built-in.o arch/arm/lib/built-in.o board/emulation/common/built-in.o board/emulation/qemu-arm/built-in.o boot/built-in.o cmd/built-in.o common/built-in.o disk/built-in.o drivers/built-in.o drivers/usb/cdns3/built-in.o drivers/usb/common/built-in.o drivers/usb/dwc3/built-in.o drivers/usb/emul/built-in.o drivers/usb/eth/built-in.o drivers/usb/host/built-in.o drivers/usb/mtu3/built-in.o drivers/usb/musb-new/built-in.o drivers/usb/musb/built-in.o drivers/usb/phy/built-in.o drivers/usb/ulpi/built-in.o env/built-in.o fs/built-in.o lib/built-in.o net/built-in.o --no-whole-archive -L /usr/lib/gcc-cross/aarch64-linux-gnu/9 -lgcc -Map u-boot.map; true
    aarch64-linux-gnu-objcopy --gap-fill=0xff -j .text -j .secure_text -j .secure_data -j .rodata -j .data -j .u_boot_list -j .rela.dyn -j .got -j .got.plt -j .binman_sym_table -j .text_rest -j .dtb.init.rodata -j .efi_runtime -j .efi_runtime_rel -O srec u-boot u-boot.srec
    aarch64-linux-gnu-objcopy --gap-fill=0xff -j .text -j .secure_text -j .secure_data -j .rodata -j .data -j .u_boot_list -j .rela.dyn -j .got -j .got.plt -j .binman_sym_table -j .text_rest -j .dtb.init.rodata -j .efi_runtime -j .efi_runtime_rel -O binary u-boot u-boot-nodtb.bin && { echo ' start=$(aarch64-linux-gnu-nm | grep __rel_dyn_start | cut -f 1 -d '\'' '\''); end=$(aarch64-linux-gnu-nm | grep __rel_dyn_end | cut -f 1 -d '\'' '\''); tools/relocate-rela $start $end'; start=$(aarch64-linux-gnu-nm u-boot | grep __rel_dyn_start | cut -f 1 -d ' '); end=$(aarch64-linux-gnu-nm u-boot | grep __rel_dyn_end | cut -f 1 -d ' '); tools/relocate-rela u-boot-nodtb.bin  0x00000000 $start $end; } || { rm -f u-boot-nodtb.bin; false; }
    start=$(aarch64-linux-gnu-nm | grep __rel_dyn_start | cut -f 1 -d ' '); end=$(aarch64-linux-gnu-nm | grep __rel_dyn_end | cut -f 1 -d ' '); tools/relocate-rela $start $end
    cp u-boot-nodtb.bin u-boot.bin
    aarch64-linux-gnu-objdump -t u-boot > u-boot.sym
....
这里的链接器就是  aarch64-linux-gnu-ld.bfd。链接脚本就是u-boot.lds，用“-T”命令行选项来指定。输入文件就是各个目录下编译好的build-in.o以及lib库。输出文件就是u-boot，通过“-o”命令行选项来指定。
千呼万唤始出来，我们来看看u-boot.lds这个链接脚本长的帅不帅：
linuxer@linuxer-virtual-machine:~/work/u-boot-2022.01$ vim u-boot.lds
OUTPUT_FORMAT("elf64-littleaarch64", "elf64-littleaarch64", "elf64-littleaarch64")
OUTPUT_ARCH(aarch64)
ENTRY(_start)
SECTIONS
{
  . = 0x00000000;
  . = ALIGN(8);
  .text :
  {
    *(.__image_copy_start)
    arch/arm/cpu/armv8/start.o (.text*)
  }
  .efi_runtime : {
                                __efi_runtime_start = .;
    *(.text.efi_runtime*)
    *(.rodata.efi_runtime*)
    *(.data.efi_runtime*)
                                __efi_runtime_stop = .;
【硬件工程师|编译器是如何将芯片执行的第一个指令放到芯片起始地址的（）】  }
  .text_rest :
  {
    *(.text*)
  }
  . = ALIGN(8);
  .rodata  : { *(SORT_BY_ALIGNMENT(SORT_BY_NAME(.rodata*))) }
  . = ALIGN(8);
  .data : {
    *(.data*)
  }
  . = ALIGN(8);
  . = .;
  . = ALIGN(8);
  .u_boot_list : {
    KEEP(*(SORT(.u_boot_list*)));
  }
  . = ALIGN(8);
  .efi_runtime_rel : {
                                __efi_runtime_rel_start = .;
    *(.rel*.efi_runtime)
    *(.rel*.efi_runtime.*)
linuxer@linuxer-virtual-machine:~/work/u-boot-2022.01$ cat u-boot.lds
OUTPUT_FORMAT("elf64-littleaarch64", "elf64-littleaarch64", "elf64-littleaarch64")
OUTPUT_ARCH(aarch64)
ENTRY(_start)
SECTIONS
{
  . = 0x00000000;
  . = ALIGN(8);
  .text :
  {
    *(.__image_copy_start)
    arch/arm/cpu/armv8/start.o (.text*)
  }
  .efi_runtime : {
                                __efi_runtime_start = .;
    *(.text.efi_runtime*)
    *(.rodata.efi_runtime*)
    *(.data.efi_runtime*)
                                __efi_runtime_stop = .;
  }
  .text_rest :
  {
    *(.text*)
  }
  . = ALIGN(8);
  .rodata : { *(SORT_BY_ALIGNMENT(SORT_BY_NAME(.rodata*))) }
  . = ALIGN(8);
  .data : {
    *(.data*)
  }
  . = ALIGN(8);
  . = .;
  . = ALIGN(8);
  .u_boot_list : {
    KEEP(*(SORT(.u_boot_list*)));
  }
  . = ALIGN(8);
  .efi_runtime_rel : {
                                __efi_runtime_rel_start = .;
    *(.rel*.efi_runtime)
    *(.rel*.efi_runtime.*)
                                __efi_runtime_rel_stop = .;
  }
  . = ALIGN(8);
  .image_copy_end :
  {
    *(.__image_copy_end)
  }
  . = ALIGN(8);
  .rel_dyn_start :
  {
    *(.__rel_dyn_start)
  }
  .rela.dyn  : {
    *(.rela*)
  }
  .rel_dyn_end :
  {
    *(.__rel_dyn_end)
  }
  _end = .;
  . = ALIGN(8);
  .bss_start : {
    KEEP(*(.__bss_start));
  }
  .bss : {
    *(.bss*)
      . = ALIGN(8);
  }
  .bss_end : {
    KEEP(*(.__bss_end));
  }
  /DISCARD/ : { *(.dynsym) }
  /DISCARD/ : { *(.dynstr*) }
  /DISCARD/ : { *(.dynamic*) }
  /DISCARD/ : { *(.plt*) }
  /DISCARD/ : { *(.interp*) }
  /DISCARD/ : { *(.gnu*) }
}
咋一看是不是挺帅的，好，那我们来认识一下这位大帅哥。
他首先是一个文本文件，里面有一系列命令。其中SECTIONS该命令用于描述输出文件的内存布局，它后面跟着花括号中的一些列符号分配和输出段的描述。该命令的第一行设定了特殊符号“.”的值，“.”值是位置计数器。如果不用其他方式指定输出段的地址，地址从位置计数器的当前值开始计算。在SECTIONS命令的最开始，位置计数器的值是0。
接下来定义输出段“.text”。冒号是必需的格式。在输出段的名称后有一个花括号，里面可以列举放入该输出段的输入段。“*”是匹配任何文件名的通配符。表达式“*(.__image_copy_start)”表示所有输入文件中的所有“.__image_copy_start”输入段。接下来是表达式“arch/arm/cpu/armv8/start.o（.text*）”表示所有输入文件中的“.text”段的arch/arm/cpu/armv8/start.o。
题主的关切点来了：
U-Boot执行的第一条指令用链接脚本中的术语叫做“入口点”。链接脚本中使用ENTRY命令来设置。参数是一个符号名称：ENTRY(symol)，这里的符号就是"_start"。这里的“_start”是什么呢？就是0x0，查看方式如下：

文章图片

那么0x0后面放什么呢？摘取关键部分如下：
  . = 0x00000000;
  . = ALIGN(8);
  .text :
  {
    *(.__image_copy_start)
    arch/arm/cpu/armv8/start.o (.text*)
  }
0x0后面放text段，text段里面先放什么呢？就是“*(.__image_copy_start)”，是什么呢，还是0x0：


文章图片

下面就是主角的真面目了，就是arch/arm/cpu/armv8/start.o (.text*)，再揭开面纱一睹真容：
linuxer@linuxer-virtual-machine:~/work/u-boot-2022.01$ vim arch/arm/cpu/armv8/start.S
  *************************************************************************/

.globl _start
_start:
                b reset
                .align 3
....
懂了吧，现在知道为啥“b reset”就会放在存储介质的0地址了吧，圆满解答题主的问题。

2022/04/03更新（没想到阅读量已快1千，感谢知友的赞同和追更）：
关于链接脚本的入口点的补充：
前面提到，可以使用ENTRY链接脚本命令设置入口点。其实链接器支持多种方式设置入口点，会按照如下优先顺序尝试设定入口点：
.“-e”入口命令行选项。
.链接脚本中的ENTRY（symbol）命令。
.已经定义的目标特定符号的值。通常是start。
.链接脚本段中第一个字节的地址。
.地址0。
光说不练假把式，实验来检验。
实验一：屏蔽链接脚本中的“ENTRY(_start)"和"arch/arm/cpu/armv8/start.o"


文章图片

重新编译后，查看映射表不再是从“b reset”开始了，直接是“__arm_smccc_smc”函数：
$ less System.map
0000000000000000 T __arm_smccc_smc
0000000000000000 T __efi_runtime_start
0000000000000000 T __image_copy_start
000000000000002c T __arm_smccc_hvc
0000000000000058 T invoke_psci_fn
00000000000000d4 T efi_reset_system
0000000000000130 W efi_get_time
0000000000000138 W efi_set_time
这种情况直接走顺序4，而.text段描述并没有指定具体内容，顺着肯定就是.efi_runtime段的第一个字节了。
实验二：保留ENTRY(_start)，并将“arch/arm/cpu/armv8/start.o”替换为“*(.text)*”：


文章图片

这种情况扔能通过"ENTRY(_start)"找到对应入口：
$ less System.map
0000000000000000 T __image_copy_start
0000000000000000 T _start
0000000000000008 T _TEXT_BASE
0000000000000010 T _end_ofs
0000000000000018 T _bss_start_ofs
0000000000000020 T _bss_end_ofs
0000000000000028 t reset
000000000000002c T save_boot_params_ret
但无法直接看出是哪个.o，实际确实是“arch/arm/cpu/armv8/start.o”，因为只有"arch/arm/cpu/armv8/start.S"定义了".globl _start"。
这种情况直接走顺序3。
实验三：删除“ENTRY(_start)"，并将“arch/arm/cpu/armv8/start.o”替换为“*(.text)*”：


文章图片

扔能找到arch/arm/cpu/armv8/start.S作为入口：
$ less System.map
0000000000000000 T __image_copy_start
0000000000000000 T _start
0000000000000008 T _TEXT_BASE
0000000000000010 T _end_ofs
0000000000000018 T _bss_start_ofs
0000000000000020 T _bss_end_ofs
0000000000000028 t reset
000000000000002c T save_boot_params_ret
这种情况直接走顺序4。
剩下的实验就交给你啦。

推荐阅读

• 

  什么是碱性岩
• 

  洛阳奥斯卡影院6月13号放映什么电影？洛阳奥斯卡影院今日放映表
• 

  京东“京银计划” 是什么 怎么参与？
• 

  共栅极放大电路分析,场效应管共栅极放大电路
• 

  2022年三伏天时间表？
• 

  活珠子不适合哪些人吃
• 

  m当前“最接近完美”的五款手机，别看价格贵，用三年毫无压力
• 

  上海电商有哪些 什么是电商上海，什么是电商上海人
• 

  家用茶具多少钱的合适 – 高档茶盘图片价格表
• 

  冰箱不结冰是怎么回事？原因分析与解决方法
• 

  热水器不烧水怎么办,是因为这些原因
• 

  增加注册资本后股东的股权比例
• 

  白发傅筹第几集知道身世
• 

  CPB水前肌底精华好不好？CPB水前肌底精华怎么用
• 

  兄弟T310如何清零废墨？
• 

  炒杜仲与生杜仲的区别 炒杜仲与生杜仲的不同之处
• 

  《侠客风云传前传》激活方法及特权简单介绍
• 

  取暖器品牌排名？哪个比较好的？
• 

  中风|女性中风有奇特症状？盘点易被女性忽视的11个中风症状！
• 

  减肥可以吃红枣吗

• 「云原生的进阶之路」|【Docker 那些事儿】关于容器底层技术的奥秘
• 「云原生的进阶之路」|【Docker 那些事儿】如何安全地停止、删除容器
• docker|Docker（将docker容器保存为docker镜像（打成tar包））
• 「云原生的进阶之路」|【Docker 那些事儿】关于Namespace隔离机制的奥秘
• docker|Docker删除镜像和容器命令
• docker|docker删除镜像和容器
• k8s|容器这么傲娇，全靠 K8S 撑腰
• 「云原生的进阶之路」|【Docker 那些事儿】容器为什么傲娇（全靠镜像撑腰）
• kubernetes|Kubernetes快速实战与核心原理剖析