当然，并不是只有这一种对象文件格式。常用格式的还有OMF-对象模型文件（Object Module File）以及ELF-可执行及连接文件格式（Executable and Linking Format）。OMF是一大群IT巨头在n年制定的一种格式，在Windows平台上很常见。大家喜欢的Borland公司现在使用的目标文件就是这种格式。MS和Intel在n年前用的也是这种格式，现在都改投异侧，用COFF格式了。ELF格式在非Windows平台上使用得比较多，在Windows平台基本上没见过。做为程序员，很有必要认识一下这些你经常打交道的家伙！不过这次让我介绍COFF先！
让我们先来看一下COFF文件的整体结构，看看它到底长得什么样！
|
如左图： COFF文件一共有8种数据，自上而下分别为： 1. 文件头（File Header） 2. 可选头（Optional Header） 3. 段落头（Section Header） 4. 段落数据（Section Data） 5. 重定位表（Relocation Directives） 6. 行号表（Line Numbers） 7. 符号表（Symbol Table） 8. 字符串表（String Table） |
| 值 | 名称 | 说明 |
| 0x0001 | F_RELFLG | 无重定位信息标记。这个标记指出COFF文件中没有重定位信息。通常在目标文件中这个标记们为0，在可执行文件中为1。 |
| 0x0002 | F_EXEC | 可执行标记。这个标记指出 COFF 文件中所有符号已经解析， COFF 文件应该被认为是可执行文件。 |
| 0x0004 | F_LNNO | 文件中所有行号已经被去掉。 |
| 0x0008 | F_LSYMS | 文件中的符号信息已经被去掉。 |
| 0x0100 | F_AR32WR | 些标记指出文件是 32 位的 Little-Endian COFF 文件。 |
这个表的内容并不全面，但在目标文件中，常用的也就只有这些。其它的标记我将在以后介绍PE格式时给出。
可选头
可选头接在文件头的后面，也就是从COFF文件的0x0014偏移处开始。长度可以为0。不同长度的可选头，其结构也不同。标准的可选头长度为24或28字节，通常是28啦。这里我就只介绍长度为28的可选头。（因为这种头的长度是自定义的，不同的人定义的结果就不一样，我只能选一种最常用的头来介绍，别的我也不知道）
这种头的结构如下：
typedef struct {
unsigned short usMagic; // 魔法数字
unsigned short usVersion; // 版本标识
unsigned long ulTextSize; // 正文（text）段大小
unsigned long ulInitDataSZ; // 已初始化数据段大小
unsigned long ulUninitDataSZ; // 未初始化数据段大小
unsigned long ulEntry; // 入口点
unsigned long ulTextBase; // 正文段基址
unsigned long ulDataBase; // 数据段基址（在PE32中才有）
} OPTHDR;
第一个成员usMagic还是魔法数字，不过这回它的值应该为0x010b或0x0107。当值为0x010b时，说明COFF文件是一个一般的可执行文件；当值为，0x0107时，COFF则为一个ROM镜像文件。
usVersion是COFF文件的版本，ulTextSize是这个可执行COFF的正文段长度，ulInitDataSZ和ulUninitDataSZ分别为已初始化数据段和未初始化数据段的长度。
ulEntry是程序的入口点，也就是COFF载入内存时正文段的位置（EIP寄存器的值），当COFF文件是一个动态库时，入口点也就是动态库的入口函数。
ulTextBase是正文段的基址。
ulDataBase是数据段基址。
其实在这些成员中，只要注意usMagic和ulEntry就可以了。
段落头紧跟在可选头的后面（如果可选头的长度为0，那么它就是紧跟在文件头后）。它的长度为36个字节，如下：
typedef struct {
char cName[8]; // 段名
unsigned long ulVSize; // 虚拟大小
unsigned long ulVAddr; // 虚拟地址
unsigned long ulSize; // 段长度
unsigned long ulSecOffset; // 段数据偏移
unsigned long ulRelOffset; // 段重定位表偏移
unsigned long ulLNOffset; // 行号表偏移
unsigned short ulNumRel; // 重定位表长度
unsigned short ulNumLN; // 行号表长度
unsigned long ulFlags; // 段标识
} SECHDR;
这个头可是个重要的头头，我们要用到的最终信息就由它来描述。一个COFF文件可以不要其它的节，但文件头和段落头这两节是必不可少的。
cName用来保存段名，常用的段名有.text，.data，.comment，.bss等。.text段是正文段，通常也就是代码段；.data是数据段，在这个数据段中所保存的数据是初始化过的数据；.bss段也可以用来保存数据，不过这里的数据是未初始化的，这个段也是一个空段；.comment段，看名字也知道，它是注释段，用来保存一些编译信息，算是对COFF文件的注释。
ulVSize是段数据载入内存时的大小。只在可执行文件中有效，在目标文件中总为0。如果它的长度大于段的实际长度，则多的部分将用0来填充。
ulVAddr是段数据载入或连接时的虚拟地址。对于可执行文件来说，这个地址是相对于它的地址空间而言。当可执行文件被载入内存时，这个地址就是段中数据的第一个字节的位置。而对于目标文件而言，这只是重定位时，段数据当前位置的一个偏移量。为了计算方便，便定位的计算简化，它通常设为0。
ulSize这才是段中数据的实际长度，也就是段数据的长度，在读取段数据时就由它来确定要读多少字节。
ulSecOffset是段数据在COFF文件中的偏移量。
ulRelOffset是该段的重定位信息的偏移量。它指向了重定位表的一个记录。
ulLNOffset是该段的行号表的偏移量。它指向的是行号表中的一个记录。
ulNumRel是重定位信息的记录数。从ulRelOffset指向的记录开始，到第ulNumRel个记录为止，都是该段的重定位信息。
ulNumLN和ulNumRel相似。不过它是行号信息的记录数。
ulFlags是该段的属性标识。其值如下表：
| 值 | 名称 | 说明 |
| 0x0020 | STYP_TEXT | 正文段标识，说明该段是代码。 |
| 0x0040 | STYP_DATA | 数据段标识，有些标识的段将用来保存已初始化数据。 |
| 0x0080 | STYP_BSS | 有这个标识段也是用来保存数据，不过这里的数据是未初始化数据。 |
注意，在BSS段中，ulVSize、ulVAddr、ulSize、ulSecOffset、ulRelOffset、ulLNOffset、ulNumRel、ulNumLN的值都为0。（上表只是部分值，其它值在PE格式中介绍，后同）
“人”如其名，这里是保存各个段的数据的位置。不同类型的段，数据的内容、结构也不尽相同。但在目标文件中，这些数据都是原始数据（Raw Data）。不存在什么特别的格式。
重定位表
这个表所保存的是各个段的重定位信息。这是一张很大的表，因为所有段的重定位信息都在这个表里。各个段落头记录了自己的重定位信息的偏移和数量。要用到重定位信息时就到这个表里来读。当然，你也可以把整个重定位表看成多个重定位表，每个段落都有一个自己的重定位表。这个表只在目标文件中有，可执行文件中是不存在这个表的。
既然有表，那么就会有记录。重定位表中的每一条记录就是一条重定位信息。这个记录的结构很简单，如下：
typedef struct {
unsigned long ulAddr; // 定位偏移
unsigned long ulSymbol; // 符号
unsigned short usType; // 定位类型
} RELOC;
有够简单吧，一共只三个成员！ulAddr是要定位的内容在段内偏移。比如：一个正文段，起始位置为0x010，ulAddr的值为0x05，那你的定位信息就要写在0x15处。而且信息的长度要看你的代码的类型，32位的代码要写4个字节，16位的就只要字2个字节。
ulSymbol是符号索引，它指向符号表中的一个记录。注意，这里是索引，不是偏移！它只是符号表中的一个记录的记录号。这个成员指明了重定位信息所对映的符号。
usType是重定位类型的标识。32位代码中，通常只用两种定位方式。一是绝对定位，二是相对定位。其代码如下：
| 值 | 名称 | 说明 |
| 6 | RELOC_ADDR32 | 32位绝对定位。 |
| 20 | RELOC_REL32 | 32位相对定位。 |
对于不同的处理器，这些值也不尽相同。这里给出的是i386平台上最常用的两个种定位方式的标识。
其定位方式如下：
绝对定位
在绝对定位方式下，你要给出符号的绝对地址（注意，有时候这里可能不是地址，而是值，对于常量来说，你不用给出它的地值，只用给出它的值）。当然，这个地址也不是现成的，你要用符号的相对地址＋它所在段的相对地址来得到它的绝对地址。
公式：符号绝对地址＝段偏移＋符号偏移
这些偏移量你要分别从段落头和符号表中得到。当段落要重定位时，当然还要先重定位段落，才能定位其中的符号。
相对定位
相对定位要复杂一些。它所要的地址信息是相对于当前位置的偏移，这个当前位置就是ulAddr所指向的这个偏移的绝对地址后四个字节（32位代码是四个字节，16位是两个字节）的位置。也就是用定位偏移＋当前段偏移＋机器字长÷8
公式：当前地址＝定位偏移＋当前段偏移＋机器字长÷8
有了当前地址，相对地址就好计算了。只要用符号的绝对地址减去当前地址就可以了。
公式：相对地址＝符号绝对地址-当前地址
计算好了地址，把它写到ulAddr所指向的位置，就一切OK！你已经完成了重定位的工作了。
行号表
行号表在调试时很有用。它把可执行的二进制代码与源代码的行号之间建立了对映关系。这样，当程序执行不正确时（其实正确的也可以J），我们就可以根据当前执行代码的位置得知出错源代码的行号，再加以修改。如果没有它的话，鬼才知道是哪一行出了毛病！
它的格式也很简单。只有两个成员，如下：
typedef struct {
unsigned long ulAddrORSymbol; // 代码地址或符号索引
unsigned short usLineNo; // 行号
} LINENO;
让我们先看第二个成员，usLineNo。这是一个从1开始计数的计数器，它代表源代码的行号。第一个成员ulAddrORSymbol在行号大于0时，代表源代码的地址；而当行号为0时，它就成了行号所对映的符号在符号表中的索引。下面让我们来看看符号表吧！
符号表
符号表是对象文件中用来保存符号信息的一张表，也是COFF文件中最为复杂的一张表。所有段落使用到的符号都在这个表里。它也是由很多条记录组成，每条记录都以如下结构保存：
typedef struct {
union {
char cName[8]; // 符号名称
struct {
unsigned long ulZero; // 字符串表标识
unsigned long ulOffset; // 字符串偏移
} e;
} e;
unsigned long ulValue; // 符号值
short iSection; // 符号所在段
unsigned short usType; // 符号类型
unsigned char usClass; // 符号存储类型
unsigned char usNumAux; // 符号附加记录数
} SYMENT;
cName符号名称，和前面所有的名称一样，它也是8个字节，但不同的是它在一个联合体中。和它占相同的存储空间的还有ulZero和ulOffset这两个成员。如果符号的名称只有8个字符，那很好，可以直接放到这个cName中；可是，如果名称的长度大于8个字节，这里就放不下了，只好放到字符串表中。这时候，ulZero的值就会为0，而在ulOffset中会给出我们所用的符号的名称在字符串表中的偏移。
一个符号有了名称不够，它还要有值！ulValue就是这个符号所代表的值。
iSection成员指出了这个符号所在的段落。如果它的值为0，那么这个符号就是一个外部符号，要从其它的COFF文件中解析（连接多个目标文件就是要解析这种符号）。当它的值为-1时，说明这个符号的值是一个常量，不是它在段落中的偏移。而当它的值为-2时，这个符号只是一个调试符号