第48章 MDK的编译过程及文件类型全解—零死角玩转STM32-F429系列

 

第48章     MDK的编译过程及文件类型全解

全套200集视频教程和1000页PDF教程请到秉火论坛下载：www.firebbs.cn

野火视频教程优酷观看网址：http://i.youku.com/firege

 

 

 

本章参考资料：MDK的帮助手册《ARM Development Tools》，点击MDK界面的"help->uVision Help"菜单可打开该文件。关于ELF文件格式，参考配套资料里的《ELF文件格式》文件。

在本章中讲解了非常多的文件类型，学习时请跟着教程的节奏，打开实际工程中的文件来了解。

 

相信您已经非常熟练地使用MDK创建应用程序了，平时使用MDK编写源代码，然后编译生成机器码，再把机器码下载到STM32芯片上运行，但是这个编译、下载的过程MDK究竟做了什么工作？它编译后生成的各种文件又有什么作用？本章节将对这些过程进行讲解，了解编译及下载过程有助于理解芯片的工作原理，这些知识对制作IAP(bootloader)以及读写控制器内部FLASH的应用时非常重要。

48.1 编译过程

48.1.1 编译过程简介

首先我们简单了解下MDK的编译过程，它与其它编译器的工作过程是类似的，该过程见图 481。

图 481 MDK编译过程    

编译过程生成的不同文件将在后面的小节详细说明，此处先抓住主要流程来理解。

(1)    编译，MDK软件使用的编译器是armcc和armasm，它们根据每个c/c++和汇编源文件编译成对应的以".o"为后缀名的对象文件(Object Code，也称目标文件)，其内容主要是从源文件编译得到的机器码，包含了代码、数据以及调试使用的信息；

(2)    链接，链接器armlink把各个.o文件及库文件链接成一个映像文件".axf"或".elf"；

(3)    格式转换，一般来说Windows或Linux系统使用链接器直接生成可执行映像文件elf后，内核根据该文件的信息加载后，就可以运行程序了，但在单片机平台上，需要把该文件的内容加载到芯片上，所以还需要对链接器生成的elf映像文件利用格式转换器fromelf转换成".bin"或".hex"文件，交给下载器下载到芯片的FLASH或ROM中。

48.1.2 具体工程中的编译过程

下面我们打开"多彩流水灯"的工程，以它为例进行讲解，其它工程的编译过程也是一样的，只是文件有差异。打开工程后，点击MDK的"rebuild"按钮，它会重新构建整个工程，构建的过程会在MDK下方的"Build Output"窗口输出提示信息，见图 482。

图 482 编译工程时的编译提示

构建工程的提示输出主要分6个部分，说明如下：

(1)    提示信息的第一部分说明构建过程调用的编译器。图中的编译器名字是"V5.06(build 20)"，后面附带了该编译器所在的文件夹。在电脑上打开该路径，可看到该编译器包含图 483中的各个编译工具，如armar、armasm、armcc、armlink及fromelf，后面四个工具已在图 481中已讲解，而armar是用于把.o文件打包成lib文件的。

图 483 编译工具

(2)    使用armasm编译汇编文件。图中列出了编译startup启动文件时的提示，编译后每个汇编源文件都对应有一个独立的.o文件。

(3)    使用armcc编译c/c++文件。图中列出了工程中所有的c/c++文件的提示，同样地，编译后每个c/c++源文件都对应有一个独立的.o文件。

(4)    使用armlink链接对象文件，根据程序的调用把各个.o文件的内容链接起来，最后生成程序的axf映像文件，并附带程序各个域大小的说明，包括Code、RO-data、RW-data及ZI-data的大小。

(5)    使用fromelf生成下载格式文件，它根据axf映像文件转化成hex文件，并列出编译过程出现的错误(Error)和警告(Warning)数量。

(6)    最后一段提示给出了整个构建过程消耗的时间。

构建完成后，可在工程的"Output"及"Listing"目录下找到由以上过程生成的各种文件，见图 484。

图 484 编译后Output及Listing文件夹中的内容

可以看到，每个C源文件都对应生成了.o、.d及.crf后缀的文件，还有一些额外的.dep、.hex、.axf、.htm、.lnp、.sct、.lst及.map文件。

48.2 程序的组成、存储与运行

48.2.1 CODE、RO、RW、ZI Data域及堆栈空间

在工程的编译提示输出信息中有一个语句"Program Size：Code=xx RO-data=xx RW-data=xx ZI-data=xx"，它说明了程序各个域的大小，编译后，应用程序中所有具有同一性质的数据(包括代码)被归到一个域，程序在存储或运行的时候，不同的域会呈现不同的状态，这些域的意义如下：

    Code：即代码域，它指的是编译器生成的机器指令，这些内容被存储到ROM区。

    RO-data：Read Only data，即只读数据域，它指程序中用到的只读数据，这些数据被存储在ROM区，因而程序不能修改其内容。例如C语言中const关键字定义的变量就是典型的RO-data。

    RW-data：Read Write data，即可读写数据域，它指初始化为"非0值"的可读写数据，程序刚运行时，这些数据具有非0的初始值，且运行的时候它们会常驻在RAM区，因而应用程序可以修改其内容。例如C语言中使用定义的全局变量，且定义时赋予"非0值"给该变量进行初始化。

    ZI-data：Zero Initialie data，即0初始化数据，它指初始化为"0值"的可读写数据域，它与RW-data的区别是程序刚运行时这些数据初始值全都为0，而后续运行过程与RW-data的性质一样，它们也常驻在RAM区，因而应用程序可以更改其内容。例如C语言中使用定义的全局变量，且定义时赋予"0值"给该变量进行初始化(若定义该变量时没有赋予初始值，编译器会把它当ZI-data来对待，初始化为0)；

    ZI-data的栈空间(Stack)及堆空间(Heap)：在C语言中，函数内部定义的局部变量属于栈空间，进入函数的时候从向栈空间申请内存给局部变量，退出时释放局部变量，归还内存空间。而使用malloc动态分配的变量属于堆空间。在程序中的栈空间和堆空间都是属于ZI-data区域的，这些空间都会被初始值化为0值。编译器给出的ZI-data占用的空间值中包含了堆栈的大小(经实际测试，若程序中完全没有使用malloc动态申请堆空间，编译器会优化，不把堆空间计算在内)。

综上所述，以程序的组成构件为例，它们所属的区域类别见表 481。

表 481 程序组件所属的区域

程序组件	所属类别
机器代码指令	Code
常量	RO-data
初值非0的全局变量	RW-data
初值为0的全局变量	ZI-data
局部变量	ZI-data栈空间
使用malloc动态分配的空间	ZI-data堆空间

48.2.2 程序的存储与运行

RW-data和ZI-data它们仅仅是初始值不一样而已，为什么编译器非要把它们区分开？这就涉及到程序的存储状态了，应用程序具有静止状态和运行状态。静止态的程序被存储在非易失存储器中，如STM32的内部FLASH，因而系统掉电后也能正常保存。但是当程序在运行状态的时候，程序常常需要修改一些暂存数据，由于运行速度的要求，这些数据往往存放在内存中(RAM)，掉电后这些数据会丢失。因此，程序在静止与运行的时候它在存储器中的表现是不一样的，见图 485。

图 485 应用程序的加载视图与执行视图

图中的左侧是应用程序的存储状态，右侧是运行状态，而上方是RAM存储器区域，下方是ROM存储器区域。

程序在存储状态时，RO节(RO section)及RW节都被保存在ROM区。当程序开始运行时，内核直接从ROM中读取代码，并且在执行主体代码前，会先执行一段加载代码，它把RW节数据从ROM复制到RAM，并且在RAM加入ZI节，ZI节的数据都被初始化为0。加载完后RAM区准备完毕，正式开始执行主体程序。

编译生成的RW-data的数据属于图中的RW节，ZI-data的数据属于图中的ZI节。是否需要掉电保存，这就是把RW-data与ZI-data区别开来的原因，因为在RAM创建数据的时候，默认值为0，但如果有的数据要求初值非0，那就需要使用ROM记录该初始值，运行时再复制到RAM。

STM32的RO区域不需要加载到SRAM，内核直接从FLASH读取指令运行。计算机系统的应用程序运行过程很类似，不过计算机系统的程序在存储状态时位于硬盘，执行的时候甚至会把上述的RO区域(代码、只读数据)加载到内存，加快运行速度，还有虚拟内存管理单元(MMU)辅助加载数据，使得可以运行比物理内存还大的应用程序。而STM32没有MMU，所以无法支持Linux和Windows系统。

当程序存储到STM32芯片的内部FLASH时(即ROM区)，它占用的空间是Code、RO-data及RW-data的总和，所以如果这些内容比STM32芯片的FLASH空间大，程序就无法被正常保存了。当程序在执行的时候，需要占用内部SRAM空间(即RAM区)，占用的空间包括RW-data和ZI-data。应用程序在各个状态时各区域的组成见表 482。

表 482 程序状态区域的组成

程序状态与区域	组成
程序执行时的只读区域(RO)	Code + RO data
程序执行时的可读写区域(RW)	RW data + ZI data
程序存储时占用的ROM区	Code + RO data + RW data

在MDK中，我们建立的工程一般会选择芯片型号，选择后就有确定的FLASH及SRAM大小，若代码超出了芯片的存储器的极限，编译器会提示错误，这时就需要裁剪程序了，裁剪时可针对超出的区域来优化。

48.3 编译工具链

在前面编译过程中，MDK调用了各种编译工具，平时我们直接配置MDK，不需要学习如何使用它们，但了解它们是非常有好处的。例如，若希望使用MDK编译生成bin文件的，需要在MDK中输入指令控制fromelf工具；在本章后面讲解AXF及O文件的时候，需要利用fromelf工具查看其文件信息，这都是无法直接通过MDK做到的。关于这些工具链的说明，在MDK的帮助手册《ARM Development Tools》都有详细讲解，点击MDK界面的"help->uVision Help"菜单可打开该文件。

48.3.1 设置环境变量

调用这些编译工具，需要用到Windows的"命令行提示符工具"，为了让命令行方便地找到这些工具，我们先把工具链的目录添加到系统的环境变量中。查看本机工具链所在的具体目录可根据上一小节讲解的工程编译提示输出信息中找到，如本机的路径为"D:\work\keil5\ARM\ARMCC\bin"。

1.    添加路径到PATH环境变量

本文以Win7系统为例添加工具链的路径到PATH环境变量，其它系统是类似的。

(1)    右键电脑系统的"计算机图标"，在弹出的菜单中选择"属性"，见图 486；

图 486 计算机属性页面

(2)    在弹出的属性页面依次点击"高级系统设置"->"环境变量"，在用户变量一栏中找到名为"PATH"的变量，若没有该变量，则新建一个。编辑"PATH"变量，在它的变量值中输入工具链的路径，如本机的是";D:\work\keil5\ARM\ARMCC\bin"，注意要使用"分号;"让它与其它路径分隔开，输入完毕后依次点确定，见图 487；

图 487 添加工具链路径到PATH变量

(3)    打开Windows的命令行，点击系统的"开始菜单"，在搜索框输入"cmd"，在搜索结果中点击"cmd.exe"即可打开命令行，见图 488；

图 488 打开命令行

(4)    在弹出的命令行窗口中输入"fromelf"回车，若窗口打印出formelf的帮助说明，那么路径正常，就可以开始后面的工作了；若提示"不是内部名外部命令，也不是可运行的程序…"信息，说明路径不对，请重新配置环境变量，并确认该工作目录下有编译工具链。

这个过程本质就是让命令行通过"PATH"路径找到"fromelf.exe"程序运行，默认运行"fromelf.exe"时它会输出自己的帮助信息，这就是工具链的调用过程，MDK本质上也是如此调用工具链的，只是它集成为GUI，相对于命令行对用户更友好，毕竟上述配置环境变量的过程已经让新手烦躁了。

48.3.2 armcc、armasm及armlink

接下来我们看看各个工具链的具体用法，主要以armcc为例。

1.    armcc

armcc用于把c/c++文件编译成ARM指令代码，编译后会输出ELF格式的O文件(对象、目标文件)，在命令行中输入"armcc"回车可调用该工具，它会打印帮助说明，见图 489

图 489 armcc的帮助提示

帮助提示中分三部分，第一部分是armcc版本信息，第二部分是命令的用法，第三部分是主要命令选项。

根据命令用法： armcc [options] file1 file2 ... filen ，在[option]位置可输入下面的"--arm"、"--cpu list"选项，若选项带文件输入，则把文件名填充在file1 file2…的位置，这些文件一般是c/c++文件。

例如根据它的帮助说明，"--cpu list"可列出编译器支持的所有cpu，我们在命令行中输入"armcc --cpu list"，可查看图 4810中的cpu列表。

图 4810 cpulist

打开MDK的Options for Targe->c/c++菜单，可看到MDK对编译器的控制命令，见图 4811。

图 4811 MDK的ARMCC编译选项

从该图中的命令可看到，它调用了-c、-cpu –D –g –O1等编译选项，当我们修改MDK的编译配置时，可看到该控制命令也会有相应的变化。然而我们无法在该编译选项框中输入命令，只能通过MDK提供的选项修改。

了解这些，我们就可以查询具体的MDK编译选项的具体信息了，如c/c++选项中的"Optimization：Leve 1（-O1）"是什么功能呢？首先可了解到它是"-O"命令，命令后还带个数字，查看MDK的帮助手册，在armcc编译器说明章节，可详细了解，如图 489。

图 4812 编译器选项说明

利用MDK，我们一般不需要自己调用armcc工具，但经过这样的过程我们就会对MDK有更深入的认识，面对它的各种编译选项，就不会那么头疼了。

2.    armasm

armasm是汇编器，它把汇编文件编译成O文件。与armcc类似，MDK对armasm的调用选项可在"Option for Target->Asm"页面进行配置，见图 4813。

图 4813 armasm与MDK的编译选项

3.    armlink

armlink是链接器，它把各个O文件链接组合在一起生成ELF格式的AXF文件，AXF文件是可执行的，下载器把该文件中的指令代码下载到芯片后，该芯片就能运行程序了；利用armlink还可以控制程序存储到指定的ROM或RAM地址。在MDK中可在"Option for Target->Linker"页面配置armlink选项，见图 4814。

图 4814 armlink与MDK的配置选项

链接器默认是根据芯片类型的存储器分布来生成程序的，该存储器分布被记录在工程里的sct后缀的文件中，有特殊需要的话可自行编辑该文件，改变链接器的链接方式，具体后面我们会详细讲解。

48.3.3 armar、fromelf及用户指令

armar工具用于把工程打包成库文件，fromelf可根据axf文件生成hex、bin文件，hex和bin文件是大多数下载器支持的下载文件格式。

在MDK中，针对armar和fromelf工具的选项几乎没有，仅集成了生成HEX或Lib的选项，见图 4815。

图 4815 MDK中，控制fromelf生成hex及控制armar生成lib的配置

例如如果我们想利用fromelf生成bin文件，可以在MDK的"Option for Target->User"页中添加调用fromelf的指令，见图 4816。

图 4816 在MDK中添加指令

在User配置页面中，提供了三种类型的用户指令输入框，在不同组的框输入指令，可控制指令的执行时间，分别是编译前(Before Compile c/c++ file)、构建前(Before Build/Rebuild)及构建后(After Build/Rebuild)执行。这些指令并没有限制必须是arm的编译工具链，例如如果您自己编写了python脚本，也可以在这里输入用户指令执行该脚本。

图中的生成bin文件指令调用了fromelf工具，紧跟后面的是工具的选项及输出文件名、输入文件名。由于fromelf是根据axf文件生成bin的，而axf文件又是构建(build)工程后才生成，所以我们把该指令放到"After Build/Rebuild"一栏。

48.4 MDK工程的文件类型

除了上述编译过程生成的文件，MDK工程中还包含了各种各样的文件，下面我们统一介绍，MDK工程的常见文件类型见表 483。

表 483 MDK常见的文件类型(不分大小写)

后缀	说明
Project目录下的工程文件
*.uvguix	MDK5工程的窗口布局文件，在MDK4中*.UVGUI后缀的文件功能相同
*.uvprojx	MDK5的工程文件，它使用了XML格式记录了工程结构，双击它可以打开整个工程，在MDK4中*.UVPROJ后缀的文件功能相同
*.uvoptx	MDK5的工程配置选项，包含debugger、trace configuration、breakpooints以及当前打开的文件，在MDK4中*.UVOPT后缀的文件功能相同
*.ini	某些下载器的配置记录文件
源文件
*.c	C语言源文件
*.cpp	C++语言源文件
*.h	C/C++的头文件
*.s	汇编语言的源文件
*.inc	汇编语言的头文件(使用"$include"来包含)
Output目录下的文件
*.lib	库文件
*.dep	整个工程的依赖文件
*.d	描述了对应.o的依赖的文件
*.crf	交叉引用文件，包含了浏览信息(定义、引用及标识符)
*.o	可重定位的对象文件(目标文件)
*.bin	二进制格式的映像文件，是纯粹的FLASH映像，不含任何额外信息
*.hex	Intel Hex格式的映像文件，可理解为带存储地址描述格式的bin文件
*.elf	由GCC编译生成的文件，功能跟axf文件一样，该文件不可重定位
*.axf	由ARMCC编译生成的可执行对象文件，可用于调试，该文件不可重定位
*.sct	链接器控制文件(分散加载)
*.scr	链接器产生的分散加载文件
*.lnp	MDK生成的链接输入文件，用于调用链接器时的命令输入
*.htm	链接器生成的静态调用图文件
*.build_log.htm	构建工程的日志记录文件
Listing目录下的文件
*.lst	C及汇编编译器产生的列表文件
*.map	链接器生成的列表文件，包含存储器映像分布
其它
*.ini	仿真、下载器的脚本文件

这些文件主要分为MDK相关文件、源文件以及编译、链接器生成的文件。我们以"多彩流水灯"工程为例讲解各种文件的功能。

48.4.1 uvprojx、uvoptx、uvguix及ini工程文件

在工程的"Project"目录下主要是MDK工程相关的文件，见图 4817。

图 4817 Project目录下的uvprojx、uvoptx、uvguix及ini文件

1.    uvprojx文件

uvprojx文件就是我们平时双击打开的工程文件，它记录了整个工程的结构，如芯片类型、工程包含了哪些源文件等内容，见图 4818。

图 4818 工程包含的文件、芯片类型等内容

2.    uvoptx文件

uvoptx文件记录了工程的配置选项，如下载器的类型、变量跟踪配置、断点位置以及当前已打开的文件等等，见图 4819。

图 4819 代码编辑器中已打开的文件

3.    uvguix文件

uvguix文件记录了MDK软件的GUI布局，如代码编辑区窗口的大小、编译输出提示窗口的位置等等。

图 4820 记录MDK工作环境中各个窗口的大小

uvprojx、uvoptx及uvguix都是使用XML格式记录的文件，若使用记事本打开可以看到XML代码，见图 4817。而当使用MDK软件打开时，它根据这些文件的XML记录加载工程的各种参数，使得我们每次重新打开工程时，都能恢复上一次的工作环境。

图 4821 使用记事本打开uvprojx、uvoptx及uvguix文件可看到XML格式的记录

这些工程参数都是当MDK正常退出时才会被写入保存，所以若MDK错误退出时(如使用Windows的任务管理器强制关闭)，工程配置参数的最新更改是不会被记录的，重新打开工程时要再次配置。根据这几个文件的记录类型，可以知道uvprojx文件是最重要的，删掉它我们就无法再正常打开工程了，而uvoptx及uvguix文件并不是必须的，可以删除，重新使用MDK打开uvprojx工程文件后，会以默认参数重新创建uvoptx及uvguix文件。(所以当使用Git/SVN等代码管理的时候，往往只保留uvprojx文件)

48.4.2 源文件

源文件是工程中我们最熟悉的内容了，它们就是我们编写的各种源代码，MDK支持c、cpp、h、s、inc类型的源代码文件，其中c、cpp分别是c/c++语言的源代码，h是它们的头文件，s是汇编文件，inc是汇编文件的头文件，可使用"$include"语法包含。编译器根据工程中的源文件最终生成机器码。

48.4.3 Output目录下生成的文件

点击MDK中的编译按钮，它会根据工程的配置及工程中的源文件输出各种对象和列表文件，在工程的"Options for Targe->Output->Select Folder for Objects"和"Options for Targe->Listing->Select Folder for Listings"选项配置它们的输出路径，见图 4822和图 4823。

图 4822 设置Output输出路径

图 4823设置Listing输出路径

编译后Output和Listing目录下生成的文件见图 4824。

图 4824 编译后Output及Listing文件夹中的内容

接下来我们讲解Output路径下的文件。

1.    lib库文件

在某些场合下我们希望提供给第三方一个可用的代码库，但不希望对方看到源码，这个时候我们就可以把工程生成lib文件(Library file)提供给对方，在MDK中可配置"Options for Target->Create Library"选项把工程编译成库文件，见图 4825。

图 4825 生成库文件或可执行文件

工程中生成可执行文件或库文件只能二选一，默认编译是生成可执行文件的，可执行文件即我们下载到芯片上直接运行的机器码。

得到生成的*.lib文件后，可把它像C文件一样添加到其它工程中，并在该工程调用lib提供的函数接口，除了不能看到*.lib文件的源码，在应用方面它跟C源文件没有区别。

2.    dep、d依赖文件

*.dep和*.d文件(Dependency file)记录的是工程或其它文件的依赖，主要记录了引用的头文件路径，其中*.dep是整个工程的依赖，它以工程名命名，而*.d是单个源文件的依赖，它们以对应的源文件名命名。这些记录使用文本格式存储，我们可直接使用记事本打开，见图 4826和图 4827。

图 4826 工程的dep文件内容

图 4827 bsp_led.d文件的内容

3.    crf交叉引用文件

*.crf是交叉引用文件(Cross-Reference file)，它主要包含了浏览信息(browse information)，即源代码中的宏定义、变量及函数的定义和声明的位置。

我们在代码编辑器中点击"Go To Definition Of 'xxxx'"可实现浏览跳转，见图 4828，跳转的时候，MDK就是通过*.crf文件查找出跳转位置的。

图 4828 浏览信息

通过配置MDK中的"Option for Target->Output->Browse Information"选项可以设置编译时是否生成浏览信息，见图 4829。只有勾选该选项并编译后，才能实现上面的浏览跳转功能。

图 4829 在Options forTarget中设置是否生成浏览信息

*.crf文件使用了特定的格式表示，直接用文本编辑器打开会看到大部分乱码，见图 4830，我们不作深入研究。

图 4830 crf文件内容

4.    o、axf及elf文件

*.o、*.elf、*.axf、*.bin及*.hex文件都存储了编译器根据源代码生成的机器码，根据应用场合的不同，它们又有所区别。

ELF文件说明

*.o、*.elf、*.axf以及前面提到的lib文件都是属于目标文件，它们都是使用ELF格式来存储的，关于ELF格式的详细内容请参考配套资料里的《ELF文件格式》文档了解，它讲解的是Linux下的ELF格式，与MDK使用的格式有小区别，但大致相同。在本教程中，仅讲解ELF文件的核心概念。

ELF是Executable and Linking Format的缩写，译为可执行链接格式，该格式用于记录目标文件的内容。在Linux及Windows系统下都有使用该格式的文件(或类似格式)用于记录应用程序的内容，告诉操作系统如何链接、加载及执行该应用程序。

目标文件主要有如下三种类型：

(1)    可重定位的文件(Relocatable File)，包含基础代码和数据，但它的代码及数据都没有指定绝对地址，因此它适合于与其他目标文件链接来创建可执行文件或者共享目标文件。 这种文件一般由编译器根据源代码生成。

例如MDK的armcc和armasm生成的*.o文件就是这一类，另外还有Linux的*.o 文件，Windows的 *.obj文件。

(2)    可执行文件(Executable File)，它包含适合于执行的程序，它内部组织的代码数据都有固定的地址(或相对于基地址的偏移)，系统可根据这些地址信息把程序加载到内存执行。这种文件一般由链接器根据可重定位文件链接而成，它主要是组织各个可重定位文件，给它们的代码及数据一一打上地址标号，固定其在程序内部的位置，链接后，程序内部各种代码及数据段不可再重定位(即不能再参与链接器的链接)。

例如MDK的armlink生成的*.elf及*.axf文件，(使用gcc编译工具可生成*.elf文件，用armlink生成的是*.axf文件，*.axf文件在*.elf之外，增加了调试使用的信息，其余区别不大，后面我们仅讲解*.axf文件)，另外还有Linux的/bin/bash文件，Windows的*.exe文件。

(3)    共享目标文件(Shared Object File)， 它的定义比较难理解，我们直接举例，MDK生成的*.lib文件就属于共享目标文件，它可以继续参与链接，加入到可执行文件之中。另外，Linux的.so，如/lib/ glibc-2.5.so，Windows的DLL都属于这一类。

o文件与axf文件的关系

根据上面的分类，我们了解到，*.axf文件是由多个*.o文件链接而成的，而*.o文件由相应的源文件编译而成，一个源文件对应一个*.o文件。它们的关系见图 4831。

图 4831*.axf文件与*.o文件的关系

图中的中间代表的是armlink链接器，在它的右侧是输入链接器的*.o文件，左侧是它输出的