2） C编译器

　　GNU编译器集GCC是通过使用一种叫做“寄存器转换语言”（RTL）的方式实现的。假定现在有一种基本的机器描述性文件，它已经能满足大家的需要。现在要做的仅仅是设置默认情况下使用的参数和如何将文件组合成可执行文件的方式。GNU的文档提供了所有必需的资料，使得用户可以为新型的处理器的指令集合提供支持。如果要针对体系的机器建立一个新的目标机器，那么就必须指定默认编译参数和定制系统的特定参数，见例2。对于特定的目标系统，可以使用TARGET_DEFAULT宏来在target.h文件中定义编译器的开关。目标t-makefile段指定了应该构建哪一个额外的例程和其编译的方式。

　　例2 使用uClinux-arm.h来指定默认的编译参数

#undef TARGET_DEFAULT
#define TARGET_DEFAULT(ARM_FLAG_APCS_32|ARM_FLAG_NO_GOT)

　　4 可执行文件格式

　　先对一些名词作一些说明：

　　coff（common object file format）：一种通用的对象文件格式。

　　elf（excutive linked file）：一种为Linux系统所采用的通用文件格式，支持动态连接。

　　flat：elf格式有很大的文件头，flat文件对文件头和一些段信息做了简化。

　　uClinux系统使用flat可执行文件格式，gcc的编译器不能直接形成这种文件格式，但是可以形成coff或elf格式的可执行文件，这两种文件需要coff2flt或elf2flt工具进行格式转化，形成flat文件。当用户执行一个应用时，内核的执行文件加载器将对flat文件进行进一步处理，主要是对reloc段进行修正。以下对reloc段进一步讨论。

　　需要reloc段的根本原因是，程序在连接时连接器所假定的程序运行空间与实际程序加载到的内存空间不同。假如有这样一条指令：

jsr app_start;

　　这一条指令采用直接寻址，跳转到app_start地址处执行，连接程序将在编译完成是计算出app_start的实际地址（设若实际地址为0x10000），这个实际地址是根据ld文件计算出来（因为连接器假定该程序将被加载到由ld文件指明的内存空间）。但实际上由于内存分配的关系，操作系统在加载时无法保证程序将按ld文件加载。这时如果程序仍然跳转到绝对地址0x10000处执行，通常情况这是不正确的。一个解决办法是增加一个存储空间，用于存储app_start的实际地址，设若使用变量addr表示这个存储空间。则以上这句程序将改为：

movl addr, a0;
jsr (a0);

　　增加的变量addr将在数据段中占用一个4字节的空间，连接器将app_start的绝对地址存储到该变量。在可执行文件加载时，可执行文件加载器根据程序将要加载的内存空间计算出app_start在内存中的实际位置，写入addr变量。系统在实际处理时不需要知道这个变量的确切存储位置（也不可能知道），系统只要对整个reloc段进行处理就可以了（reloc段有标识，系统可以读出来）。处理很简单，只需要对reloc段中存储的值统一加上一个偏置（如果加载的空间比预想的要靠前，实际上是减去一个偏移量）。偏置由实际的物理地址起始值同ld文件指定的地址起始值相减计算出。这种reloc的方式部分是由uClinux的内存分配问题引起的。

　　7 总结

　　以上主要阐述了嵌入式操作系统uClinux的内核结构、、内存管理、多进程处理、针对实时性的解决方案和开发环境，先对uCLinux有一个深刻的认识，将有利于今后进一步研究开发。

　　(参考链接: http://linux.ccidnet.com/art/310/20070112/999897_1.html)