（1）连接脚本中指定的（或者是在arm-linux-ld命令行中用参数Ttext指定的）运行地址，在运行程序不是位置无关码的时候将直接影响最后生成的 二进制运行代码是什么（即最后生成的二进制代码随这个指定的运行地址不同而不同）。而加载地址是否能影响生成代码见下面（2）（3）结论。
（2）如果连接脚本中指定了加载地址，并且脚本中还定义了等于加载地址（或与加载地址相关的）的一些符号（地址变量），而源程序中又引用了 这些符号来编程（通常引用这些与这些加载地址相关的符号是为了将代码从NAND/NOR上搬运到指定的运行地址上），那么可以说加载地址同样也影响 最后生成的二进制运行代码是什么。
（3）如果连接脚本中指定了加载地址，并且脚本中还定义了等于加载地址（或与加载地址相关的）的一些符号（地址变量），而源程序中根本没有 引用这些符号来编程，那么可以说加载地址根本不影响最后生成的二进制运行代码是什么。但是这个加载地址的信息将残留在连接后生成的文件中：在装了操作系统的台式机中，由操作系统将这个连接生成的ELF文件调入进入内存运行，而究竟调入内存什么位置就要根据此ELF文件中的加载地址信息；如果是嵌入式系统中的应用的话，我们首先用arm-linux-bjcopy将此ELF格式转换成纯净的二进制BIN 格式，然后再将BIN文件烧入NAND FLASH或者NOR FLASH中。在此BIN文件中仍然要反映出这个加载地址的信息，往往需要填充空白的0使得被指定了加载地址的段确实是定位到指定的那个加载地址上。（请参考我的另一个帖子 ）
（4）_TEXT_BASE=0x33f80000是运行地址而不是加载地址。对于位置无关代码它可以在内存中任何地址正常运行。
（5）u-boot.lds中肯定已经指定了加载地址在0。ARM都是从0地址开始运行，如果UBOOT不加载到0地址开始运行就失去了bootloader的功能和意义了。
====
-----------------------------------------------------------------------------------------------------------------------------------
烧入NAND中的BIN文件中除了代码还有其他定位信息？
P137最后一行那个连接脚本，main.o的加载地址在4096，与运行地址0X30000000不同。那么用P81的sjf2410.exe（或者sjf2440.exe）软件烧入NAND的最终的BIN文件中，一 定有4096这个加载地址的信息吧？（否则sjf2410.exe软件怎么知道要把second段烧到NAND中4096开始的地方，而不是紧接着first段？！）
因为前面的first段不会用完4096个字节，所以first段的末尾到4096之间就有个空洞。那么BIN文件中是（1）将空洞全部定义为某个值比如0呢，还是（2）根本不对这个空 洞部分的值做定义呢？在前一种（1）的情况下，BIN文件不会傻到老老实实地空洞有多大就填满多少个0吧? 推测应该会有个简短的语法格式来说明有几个0。这样的话4096 这个地址值数字肯定会“显式”地出现在BIN文件中。如果是第二种情况的话，推测更应该这样有4096这个数字在BIN文件里了。
总而言之，我的理解就是BIN文件并不是完全纯粹的代码，还是有其他信息的在里面，比如定位信息。
本来在LINUX里试验一下生成BIN文件再用ULTRAEDIT看看就可以了，可是这几天我的LINUX系统坏了，所以先自己推测一下。
请作者和网友指点一下，不知道我的理解是否正确。
------------------------------------------------------------------
回复：烧入NAND中的BIN文件中除了代码还有其他定位信息？
BIN文件不会傻到老老实实地空洞有多大就填满多少个0吧
===> 就是这样的
====
阅读(1173) | 评论(0) | 转发(0) |
