程序如何在内存中执行？

前言

1. 这里只是我自己对cpu如何加载程序运行以及代码重定位的理解，不一定对。
2. Nor-flash的接口和sram的接口一样，都可以对字节进行寻址，而nand-flash只能对块进行寻址，一个块可能有256字节，所以程序要加载到ram或者nor-flash进行运行，因为PC指针指向的是下一条要运行的指令的地址，所以pc指针必须要字节寻找。
3. 一些小的单片机，例如cortex-m3系列的，他的程序是烧录在内部的nor-falsh上面的，运行也是直接在nor-flash上，不用加载到ram。
4. 所有真实的物理地址寻址方向一定是低的物理地址放代码段、数据段和bss段，高的物理地址放堆栈段。
5. 重定位就是将程序的逻辑地址空间变换为实际的物理地址的过程。
6. 异常向量表在内存中的地址是固定的，当异常发生时，CPU将强制pc寄存器加载异常向量表的地址，执行异常处理代码，中断是异常的一种。固化的rom-code，uboot或者linux都会设置异常向量表对应的处理代码。例如rom-code里可能会设置重启和复位的代码，uboot和linux可能会设置中断的一些代码。向量表的地址不总是从0开始的，芯片内部可能有专门的寄存器来设置向量表的地址，表中各个向量的偏移地址一般是固定的，例如0地址处肯定是复位向量。

裸机：（这里特指一般的普通arm单片机，排除有很多奇奇怪怪的cpu结构的单片机）

  我只用过arm的，所以别的我不太清楚。
  Arm的Cortex-M系列是哈弗总线结构，A及以上的系列是混合结构。

1.Cortex-M系列的单片机

  一般是编译器将代码编译为一个hex文件，然后将该hex文件通过烧录器烧录到单片机内部的norflash里面，而且从地址由高到低一般是代码区、ro-data、rw-data、zi-data。
  代码区：在程序运行前就确定了，只读的不可更改。
  ro-data区：常量区
  rw-data区：已经初始化的全局和static变量
  zi-data区：没初始化或者代码中初始化为0的全局和static变量
  在单片机上电的时候一般pc指针的值为0000，即执行norflash的第一句代码，这个代码不是你写的main函数，而是异常向量表的复位向量地址，这个地方存放的是单片机的固定初始化代码（也别管怎么来的，反正是copy别人的工程），比如工程中的start.s或者setup.c，他们会设置和初始化cpu的状态，然后rwdata区的数据和zidata区域的数据拷贝到sram，然后根据启动文件中的堆栈或者编译器默认设置的堆栈大小来设置堆栈。其中zi-data段的数据会全部写0，堆栈大小是我们能通过修改启动文件或者编译器人为设置的。然后cpu读取指令从norflash读，然后读写数据从sram中读写，哈弗总线结构。
  他的代码执行的时候只重定位了rw-data和zi-data段。代码段中访问变量的地址本来就是相对于某个段的相对地址，即编译器和链接器在生成代码时只要物理地址设为段地址+相对偏移即可，程序中所有的地址都是确定的。这个rw-data段和zi-data段的地址即sram的首地址，整个拷贝过程是系统的初始化代码设置的。

2.A系列及以上的处理器

  一般都有专门的内存分配单元（MMU），一般把代码存放到nand-flash上。在系统启动时一般会执行芯片内固化的rom-code或者是在CPU上电时会自动将nand-flash上固定大小的代码段拷贝到ram中运行，MMU会将ram映射为地址0000。这段代码会执行代码段和数据段拷贝的工作。这段初始化代码会将nand-flash中的代码的各个段拷贝到ram的固定位置。（其实我也不是很懂，不同的处理器好像机制不一样）

Linux ELF文件：

  Linux下的elf有三种，库文件（.so/.a）、源码编译生成的目标文件（.o）和可执行文件。其中可执行文件和目标文件的唯一区别是他有一个指定的入口函数，即main函数。Linux系统中的进程内存可分为：代码段、data段、bss段、堆栈段。代码段存放的是编译和链接后的机器指令，其实存放字符串或者常量的ro-data段在我的理解里可以看成代码段。Data段存放的是已经初始化的全局和静态变量，bss段存放的是还未初始化或者初始化为0的全局和静态变量。堆栈段我就不说了。
  Linux为每个进程分配了4G的虚拟地址，操作系统只是通过mmap的方式确保虚拟地址和物理地址之间的存在单一的映射关系，但是实际的物理地址只有2个G咋办？当你写的程序内存需求过高时，即使他们没有报内存溢出的错误，他的执行效率会变慢，因为linux操作系统会进行虚拟内存扩展，进行内存页的交换，将数据刷写的磁盘上。
  程序编译和加载的过程可分为：预处理、编译、汇编、链接和加载。其中预处理是处理头文件和解宏定义及宏条件，汇编是将编译产生的汇编代码转化为机器码，所以不好搞清楚的是编译、链接和加载的过程。

1.编译器的工作

  源文件被编译器编译生成目标文件，即.o文件，目标文件中有数据段、代码段和符号表，全局和静态变量存放在数据段，函数及其定义存放在代码段，当前文件的函数和变量以及外部的变量和函数引用放在了符号表。编译器主要干了这两件事：
  1. 确定变量的内存地址
  2. 确定函数的内存地址
  这里指的地址是相对本文件的偏移地址，因为在生成一个目标文件时编译器并不知道这个目标文件要和哪些目标文件进行链接生成最后的可执行文件，而链接器是知道要链接哪些目标文件的。因此编译器仅仅生成一个相对地址。而对于外部引用的函数和变量地址只有链接器在链接的时候才知道，所有编译器生成目标文件的时候还会需要一个.rel.text段的记录来告诉链接器要修正外部引用的函数的地址，一个.rel.data段来记录告诉链接器要修正外部引用的变量的地址。
  目标文件中还存在符号表，整个符号表的作用有两个：
  1. 本目标文件能对外提供哪些全局变量和函数。
  2. 本目标文件需要使用外部的哪些变量和函数。
  很多时候我们使用C++的代码调用C语言的库的时候会出现找不到函数定义的错误。因为C++编译器在将函数生成符号表使用的是函数名字和函数形参类型，而C的编译器只使用了函数名字。这也是为什么C++可以函数重载而C不可以。符号表是给链接器用的，只要确保本目标文件引用的所有外部变量和函数都能找到定义，链接过程就不会报错。
  生成了目标文件后，编译器的工作就完成了。

2.链接器的工作

  Linux系统中寻找库文件的顺序为：
  1. gcc –L指定的路径
  2. 环境变量LD_LIBRARY_PATH等环境变量的路径
  3. Gcc默认的路径，/usr/lib、/lib等
  链接器操作的对象是目标文件，即.o文件。库文件和可执行文件都是基于目标文件生成出来的，将多个编译生成的目标文件链接生成库文件和可执行文件。
  1.程序链接时：静态链接
  2.程序加载时：动态链接
  3.程序运行时：dlopen、dlclose等系统调用函数

  静态链接：静态库是多个目标文件链接生成的，在生成可执行文件使用静态链接时，就把需要的目标文件整个链接到可执行文件中。而不是仅仅将某段代码链接进去。所以静态链接和我们在写代码时将多个源文件编译生成可执行文件没有本质的区别。静态链接过程中的主要工作：
  上面提到过编译过程中本目标文件中的函数和变量的相对地址已经确定了。但是链接器现在要合并多个目标文件，将代码段合并到一块，数据段合并到一起。计算出所有段的长度，然后修改上面说到的相对地址，即：
  最终内存地址 = 相对地址+段偏移
  然后解析每个目标文件的符号表，确定变量和地址的引用都能找到定义。这个结束后所有的变量和函数的地址都确定了，然后根据rel.data段和rel.text段的信息修改所有外部引用的变量函数地址。

  动态链接：动态链接只是将动态库的路径和名字写入到了可执行文件中，然后再程序加载时可执行文件再去根据这些信息寻找动态库链接，也就是将链接的过程推迟到了可执行文件加载时。所以生成的可执行文件会比静态链接的小，但是程序加载过程会长。