本篇文章以STM32为硬件平台，使用GNU GCC作为开发工具，详细分析Compile 、Link 、Loader的过程以及Image(二进制程序)启动的详细分析。整个过程分析涉及到RW可读写段从Flash到Mem的Copy，BSS段的初始化，Stack和Heap的初始化，C库函数移植、利用Semihosting 实现基本的IO等内容。基本可以让你从更深刻的层面理解Source -> Compile -> link -> run的整个过程。理解了这些个之后，你就对那些从语言编程层面来说难于理解的问题自然领会了，比如：为什么C语言规范里会提到变量的作用域和生命周期？全局变量和局部变量的区别到底在哪？等等一些看起来是规定的东西，工科科学里一切不自然的概念都需要你用心去理解，去实践，达到自然的状态才有可能去解决实际遇到的问题，规则只是思想包袱，不会产生任何价值，大部分情况下会阻碍你解决问题。

我们都熟悉有操作系统支持的应用程序开发，比如 Linux下C语言的开发。我们可以不用关心程序启动的细节，同时我们一般还可以使用各种方便的lib 库，比如基本的IO操作(printf scan)，动态分配内存操作(malloc)，文件操作(fopen fwrite fread)等。有操作系统支持的情况下，程序的编译、链接、启动都是有操作系统支持的，常用的编程库函数使用的是标准的C库。

那如果没有OS支持的情况下，想实现上面这些功能的话，该怎么做呐？这种情况就叫 Bare Metal (裸)程序开发。在嵌入式开发中是比较常见的情况，本blog 主要讲解基于Cortex-M3 的裸程序开发。本裸机程序实现了 基本IO，动态内存分配，基本函数库等功能。

主程序验证了基本的Startup，基本的IO功能，malloc功能，打印了全局变量和局部变量的地址(用于理解全局变量和局部变量的区别)。 其主程序代码如下：

还是和有OS支持的情况下来对比，有OS的情况下分析一个Project，一般会从3个方面来进行分析：一是看源代码的组织形式；一是看Compile && Link过程(即Makefile)；三是看Run时的情况(一般看运行起来后几个Process，几个Thread，以及他们之间的关系)。分析完这3个方面后，整个project从静到动，以及动静之间的转换都包括了，也就掌握了整个的Project。

在没有OS的情况下，1 2 两个方面是一样的，只不过程序运行的基础环境不一样，裸机程序运行需要考虑的细节多一些。裸机程序需要考虑的基本问题有：

我们按照上面说的方法，从3各方面出发，分析我们的Project。

源代码：

顶层目录：

其中src目录是Application层的主逻辑代码，其中main.c就在src目录中，是业务逻辑层的主代码。 include目录是Application层的interface 说明文件。 system 目录是和启动有关系的代码。 ldscripts目录是link 脚本，主要告诉ld(链接器)如何链接各个Objects文件为可执行程序. Debug目录是个编译目录，里面包含各种Makefile。

更详细的项目目录结构：

这里简单说明下system 目录，cmsis主要是soc相关的初始化代码，cortexm是Cortex-M3的启动相关代码，diag是使用Semihosting实现了基本的IO，newlib是newlib移植需要实现的函数，stm32f1-stdperiph 是soc片上的外设资源的Driver。

编译&&链接:

当然是直接 make 喽。

编译的模板，自己根据实际文件名进行修改

编译说明：编译单个文件其实还是挺简单，只是添加了一些功能性的宏定义。

链接的模板，自己需要添加Objects文件

链接说明：链接时使用了-nostartfiles，含义是不使用Crt0.o 提供的启动代码，库函数还是使用arm-linux-gcc提供的new-lib。

映像结构&&运行：

有操作系统的情况下，我们不需要关心可执行映像的具体结构，一个可执行程序文件从静态文件到动态运行这个过程叫Loader&&Run。这个过程是由OS来完成的，应用程序级别的开发是不需要关心这些细节的。对OS如何处理Link&&Loader这些细节感兴趣的，可以参考书籍： 1. 程序员的自我修养 2. Linkers and Loaders

我们这里处理的是裸程序的启动细节问题，首先我们要知道的是通过编译器和链接器之后得到的二进制可执行映像的结构。也就是说得出的那个 *.bin 文件里面长啥样？一图胜万言，上张图先。

我们大家都知道冯.诺依曼架构的计算机，它的基本思想是把“做事情的步骤和所需要的资源都提前编写好，然后让计算机自己根据需要读取操作步骤和资源，实现部分的计算自动化”。计算机的设计思想可谓是精妙的，实现真正的计算自动化也是很多科学家和工程师的夙愿。上面所说的做事情的步骤在计算机领域叫指令，所需要的资源在计算机领域叫数据。从计算机体系结构角度去看可执行映像的话，其实也就分为指令和数据两个大的部分。指令部分还是比较单一的，把各个源文件中的指令部分最后都汇聚到一起，形成所谓的text段。从功能上分，代码段只是需要CPU去读取，不需要修改，因为可以将其放在RO存储器里。数据这个部分从功能上来看，它必须支持读写，也即数据段执行时必须位于RW存储器里。从功能细节上分数据段又分为BSS段，Data段，Stack段，Heap段。从计算机体系结构角度来一一分析，从数据的生存周期角度来看，有的数据的生存周期和程序的生存周期是一致的(全局变量)，有的数据的生存周期是根据使用情况即时分配和释放的（局部变量、malloc动态分配的变量）。BSS段和Data段属于全生命周期的数据，在源程序里主要是那些在文件域定义的全局变量和使用static关键字定义的全生命周期变量，Data是那些在程序里定义变量时初始化为固定值的量，BSS段是那些在程序里定义变量时未初始化的变量，这些变量在映像真正执行前会自动初始化为0。对BSS段再多说一句，BSS段在映像文件里并不占用具体的空间，因为没有任何具体的信息，只需要在映像文件中提供BSS段的起始地址和大小信息即可。在映像文件实际执行前，把BSS段要求的Data区域在实际RAM中预留出来并把这些区域初始化为0。短生命周期的数据包括Heap和Stack，它们的特点是随用随申请，用完就释放，比较灵活。Heap是一段预留出来的大空间，可以根据需求随时申请和释放，就是我们常见的malloc free函数操作的空间就是Heap 空间，这部分空间在映像里是独立出来的一段空间，见上面的程序映像图。Stack也是独立预留出来的一段连续数据空间，它的作用还挺多，想更进一步了解的请看Stack在函数调用、中断（异常）、RTOS中的应用。 从程序映像角度来看，就是代码段和根据功能划分的一些数据段组成的，使用映像资源最关键的就是要知道每条指令或者具体的变量在映像文件中的Offset。也就是我们常说的Address，我们在裸机环境下所说的Address就是真实的物理地址(Physical Address)。

程序映像的事情说的差不多了，下面就得以STM32F103RBT6这种具体的Soc和arm-linux-gcc这种具体的compiler&&linker来进行详细说明。我们编译出来的映像的具体结构是什么样？整个可执行程序的入口在哪里？每个段的具体地址如何获取？可执行程序在执行前都做了哪些准备工作？下面我们来一一详细道来。 先来看看STM32F103RBT6这个soc的Memory map，还是来张图吧。

我们看到RO存储Flash Memory的地址段是：0x08000000–0x0801FFFF 共128K。 RW存储SRAM的地址段是：0x20000000–0x20004FFF 共20K。 我们Soc的启动配置是从0x08000000地址开始启动。为节约RAM空间，我们启动时映像的代码段不搬运，直接读取Flash Memory，数据段需要可读写，因此需要将所有的数据段搬移到RAM中去。大致情况见下图：

硬件情况就是这样，下面开始分析如何产生符合这款Soc的映像文件。下面一个重要的Tool出厂，link script，它控制着如何产生最终的映像文件。在分析具体的link script之前，先来说link script 里最重要的概念，Address && Offset，前面也说了，到了映像文件格式这一层面，也就剩下各种连续的内容(段)和地址(Address)了，因此地址对映像来说是一个十分重要的资源。link script 无非就是告诉链接器哪段东西放在哪个地址上。那些段需要搬运，当然搬运也是需要地址的。

来看看我们项目中用到的link script： 分连个层面来看，一是Memory Map相关的，一是段分配相关的。 先看Memory Map，

定义了一个RO存储和一个RAM存储，地址空间和Soc硬件手册一致。

再来看看各种段设置的情况，

链接脚本定义了上面提到的各种段，text、BSS、data、Stack、Heap等不同的段。定义了每个段在映像文件中的排布方式，定义了有哪些段需要在运行前从FLASH中搬运到RAM中。 我们拿出一个data段来进行说明。

上面的脚本定义了一个段叫data，里面包含了所有Objects文件中的data段，不同文件中定义的全局变量和静态变量全部汇聚到了这一个段中。里面还定义了一些label，这些label其实就是映像文件中各个数据或者段的地址(Address/Offset)，主要用于给程序提供这些地址信息，让程序对映像文件中的这些资源进行处理。你像这个data段，需要在startup初始化阶段将data段从FLASH 复制到RAM中。既然要复制，那程序就需要知道源地址，目的地址以及要复制的长度。开始地址就是data段在整个映像的Offset地址，在这里起了个名字叫data_start ，结束地址叫data_end ，知道了开始地址和结束地址也就知道了信息源的所有信息(开始地址、结束地址、长度)。那目的地址在哪？别着急，目的地址的设置是使用了 AT 这个指令，意思就是告诉链接器这段内容是需要搬运的，下载地址和运行地址是不一样的。

上面的指令意思是这个段的实际链接地址是 RAM 这个Memory Region中定义的0x20000000开始的地方，根据内容依次往后放。但现在在映像中实际的位置是FLASH 这个Memory Region中定义的0x08000000开始的地方开始放置的，根据内容依次顺序放置的。在FLASH中这个内存域中，前面可能已经放置了启动代码和其他代码段。使用了这个说明后，产生的效果是在映像文件中是连续存放的内容(以0x08000000作为基地址)，但是data段实际的链接地址都是以0x20000000作为基地址的。比如你定义了一个全局变量 int A = 88;，它实际运行的地址在0x20000010这个地址，但是在最开始整个映像都在FLASH中，它可能在映像中的实际存在位置为0x08000100。在程序最开始(还没用到这个全局变量之前)的代码中需要将data段整体地从FLASH中移动到RAM中。如果不用AT 指令的话，映像文件会直接按照链接地址生成，就意味着映像文件会很大，因为代码段0x08000000和数据段0x20000000之间有一个Gap，这个Gap需要使用大量的0来填充。想想都觉着这个映像很大。实际我们产生映像文件时是要同时考虑装载视图和运行视图这两个方面的。 本工程中搬运代码在 bare_metal_hello_world/system/src/newlib/_startup.c

看调用的函数 __initialize_data(&_sidata, &_sdata, &_edata); 咦，三个参数在哪里定义的？在链接脚本里。从调用也可以看出，链接脚本里定义的label就相当于地址，在C语言程序里要使用取地址符&。去找找看： 其中_sdata 和 _edata这两个label是在 data数据段里定义的，作为目的地址存在，其范围在RAM Memory Region中定义的范围。 _sidata是在

这里定义的，是data数据段在映像中的Offset，其范围在FLASH Memory Region中定义的范围中。

其他还有好多别的数据段，我就不一一分析了，也就data bss数据段需要启动时处理，是比较复杂的了。你像Stack和Heap段也只是分配空间，然后把起始地址，长度信息设置个label供程序使用罢了。链接脚本定义的各种label都是有用的，有的是给启动程序用的，有的是给库函数移植用的，有的是给调试器用的。

说了这么多，整个程序的入口在哪里？有OS支持的情况下，一般主函数都是main，我们裸机开发，执行的第一条指令在哪？ 看链接脚本

好像是叫 _start这个label，是个函数名称吗？先搜搜源代码看看。 还是在bare_metal_hello_world/system/src/newlib/_startup.c

CPU都有一个叫向量表的东西，就是规定了各种特殊情况下应该去执行哪里的代码。详细点说向量表包含 Interrupt 和 Exception两种类别。Cortex-M3也有自己的vectors。

上面只是列举了一部分Vectors。可以看到有一个reset vector handler，就是说系统刚上电启动或者复位时都会执行这个地址上的代码。我们代码中在这个位置提供了什么呐？

可以看到我们的reset handler放的是 Reset_Handler 这个函数，看看这个函数干了些啥？

原来是直接调用的 _start () 函数。启动就是直接执行这个函数里的内容。 关于正常的CPU 初始化流程，网上一大堆，我们的大致流程是这样的：

前面的分析过程中其实已经涉及到一些newlib库的函数，bare_metal_hello_world/system/src/newlib/_startup.c 中涉及到一些和启动有关系的代码：包括数据段的搬移、bss段的初始化、C++运行环境的初始化等。除了这些初始化相关的功能外，newlib还需要实现那些功能？程序的退出设计(exit)、Heap管理功能实现、标准常用库函数syscall实现(open read write close等)。我们一个个来说下，程序的exit函数，需要调用底层的库函数_exit(),我们这里实现的_exit非常简单。

可以在程序退出时打印一些Debug信息。我们这里退出main函数之后，直接进入了死循环。

下面聊一聊Heap管理，主要需要实现 _sbrk 这个函数。实现这个函数的文件是： bare_metal_hello_world/system/src/newlib/_sbrk.c

我们平常使用的malloc，free等库函数，到最终都会调用_sbrk()这个函数。关于这个函数的处理流程这里不再分析，简单提一下这个Heap的起始地址和长度信息也是通过链接脚本定义的，_Heap_Begin和_Heap_Limit。 syscall的实现在 bare_metal_hello_world/system/src/newlib/_syscalls.c 基本的syscall，这里都实现为了Semihosting方式。

本项目中，基本的IO都使用Semihosting实现。打印功能，使用自己实现的trace_printf函数，没有使用newlib库的printf函数。newlib中的printf函数开销比较大，我们这个只是调试的时候需要简单的输出功能。因此，自己实现了一个简单的利用Semihosting做的打印输出功能。 bare_metal_hello_world/system/src/diag/Trace.c

实现了以下接口：

trace_printf底层会调用 Semihosting的实现函数 trace_write，bare_metal_hello_world/system/src/diag/trace_impl.c

我们在编译时使用了OS_USE_TRACE_SEMIHOSTING_DEBUG 宏定义，因此会调用_trace_write_semihosting_debug函数，这个函数调用call_host实现了Semihosting的输出到Host主机的功能。

bare_metal_hello_world/system/include/arm/semihosting.h

调试环境的使用，在基于Docker环境开发、调试嵌入式软件（Embedded Software develop/Debug using Docker）有详细的说明。

输出：

可以看到我们验证了malloc函数，可以正常工作。我们顺便验证了下全局变量和局部变量在RAM中的实际地址，test定义的是个Global的变量，可以看到地址是0x20000020，确实是在RAM Region定义的范围，地址确实是从0x20000000 开始用的。函数内的局部变量使用的是Stack的内存空间，从上面介绍的内容来看，Stack是从RAM高地址向低地址使用的，这里RAM最高地址是0x20004fff，我们local_test变量的地址是0x20004fd4，和预期情况一致。我们也测试了浮点数的打印，newlib本身没有启用浮点数的支持，要想使用浮点数的输入、输出功能，需要使用编译器链接选项 -u _printf_float 强制链接相关库函数。

本blog 中使用的源代码是来源于项目GNU MCU Eclipse的 C project工程模块，使用Eclipse创建一个基本的Cortex-M3 裸机程序的步骤见：Tutorial: Create a Blinky ARM test project。本blog只是按照自己的理解，分析了一下几个关键点和整体流程。项目作者是Liviu Ionescu. 他的另一个项目是micro-os-plus-iii,一个嵌入式软件开发基础套件，支持C api C++ api。感谢Liviu Ionescu。

2