(转载)GCC与Obj文件,动态链接文件和ELF文件

原创 2005年05月13日 22:39:00

(转载)GCC与Obj文件,动态链接文件和ELF文件     

--------------------------------------------------------------------------------
 
1、Obj文件
     程序员编写程序,其实就是编写出一个2进制(binary)文件。假如我们声明一个变量char c,也就是声明需要一个8bit的空间,那么就需要向系统声明豫留8bit的空间,怎么做到这一点呢?就是编译一个特殊的2进制文件--obj文件,用gcc编译的C语言得到的执行文件,里面不仅包含CPU指令,还有很多别的信息在里面,它有很多格式COFF、ELF……等等,在最后一道编译过程中,链接器(linker)ld会加载一堆信息进入可执行文件。例如,当有多个编译后等待链接的.o这种可重定位(relocatable)文件,既然这些文件里面参数或者函数名的相对位置只是本身所在.o文件的相对位置,就有一些信息要告诉链接编辑器(link editor)怎么修改section的内容,来做relocate,也就是做地址的重新参照以便合成一个新的可执行文件。

     一个obj文件有两个重要时期,一个是正在链接(link)的时候,也就是处在
硬盘(disk)里的时候;一个是正在执行的时候,当然这时它位于内存里。我们平时说的ld linker其实叫link editor,最后编译的步骤ld把该有的信息写进可执行文件。如果是static link就会去找libxxx.a的函数库文件,把想要的程序代码片段拷贝一份进可执行文件,并且做成relocation后,把跳来跳去的参照写进可执行文件,这个文件就可以执行。

2、动态链接文件
     相对于静态链接(static link)拷贝原有的程序代码进可执行文件,动态链接不那样做,link editor把一些信息写进可执行文件而已。例如,需要的程序库名、函数名等,最后执行的时候,必须呼叫dynamic linker來做program intepreter,dynamic linker会根据需要的函数库名称,把想要的函数名字创造一个可执行的image放到内存,所以执行有动态链接的执行文件,最后通常都是由OS的exec系列的system call与dynamic linker如ld.so联合完成。

dynamic linker通常会做如下工作:
(1)把可执行文件的内容加载到process image
(2)把shared obj需要的东西加载到process image
(3)完成relocation

      本来这些obj文件里面的虚拟地址应该和文件的地址有相对应的偏移(offset),而文件首地址通常是0x08040800,这是绝对虚拟地址,但它只适合可执行文件,例如Linux extuable file通常是:
         file offset         virtual  address
         -----------         ----------------
         0x0                   0x08048000
         0x100                 0x08048100

      shared obj函数库里的程序代码必须为位置无关代码Position Independent Code (PIC),也就是说它的地址可能会随不同process而有不同,例如,一个程序只用了libc.so、ld-linux.so,通常这时候lib.so是从0x40017000开始的,但如果另一个程序多用一个libm.so,那么libc.so从0x40034000开始两个的printf参照(reference),就会有不同的地址,所以这种动态函数库的内部资料就要说明这些code是PIC。

3、ELF文件
(1)简介
     现在最常用的是一种叫ELF格式(executable and linkable format)的执行文件,ELF定义了一些变量与信息使得动态链接更有弹性,一个ELF的2进制文件按照spec 1.1版的说法有6种,下列是较常见的:

relocatable:它就是编译时产生的.o文件,包含了代码和数据(这些数据是和其 他 重定位文件和共享的object文件一起连接时使用的)

executable:它就是最后的可执行文件,包含了代码和数据shared obj:它就是在/lib /usr/lib下那些可动态链接的函数库文件,包含了代码和数据(这些数据是在连接时候被连接器ld和运行时动态连接器使用的)

core:Core Dump时产生的文件,包含了一堆garbage数据

     注意:这些ELF文件已经是广义的2进制文件,不单指可执行文件。
   
(2)ELF组成
     一个ELF obj文件随它存在的时期有不一样的需求和组成名字,在要链接linking时期位于硬盘,包含了:
ELF header
program header table (可以不要)
section 0
section 1
section 2
section 3
section ...
section n
section header table

     ELF header放了ELF定义的一些ELF格式识别字串(俗称magic number),还有obj文件(shared obj,relocatable或者executable)这些一般(general)的信息;program header table是描述了段(segment)信息的结构数组和一些为程序运行准备的信息。segement和section不大一样,是属于程序执行时期的元素,所以在程序执行时期是必要的,在链接时期是不必要的,所以如果程序不做链接动作,只要有program header table就可以;section header table就是一个索引表,来记录各个section的索引,sections就是把需要的资料根据属性用途分门别类后的小集合,有.bss .data .init .debug .dynamic .fini .text………,其中比较重要的有:

.text
      里面保存真的CPU指令
.bss
     保存没有initialize的data
     主要是声明的global与static变量
.data
     保存initialize的data

     写程序用到的函数名,变量名分布在多个source code目录里时,需要一个
参照(reference)的信息做连接这些名字,symbol是着被给linker来做连接用的,因为obj文件分散存在,要把这些obj文件的代码集合起来,就要靠symbol来辨别,string table存有很多行字串,每行字串用NULL来分开,每行字串就是symbol和section的名字。symbol table是一张表,存有将来要定址或重新定址所要的symbol定义和参照信息。shared lib的obj文件还有.dynsym这个section,里面存有dynamic symbol table,动态链接的时候使用。另外,如果将来的程序要用debug工具调试,编译时要加-g这个选项,它会根据sumbol和string table放进debug多需要的信息给obj文件,这样的信息现在大都用一种叫stab的格式存放,这同时也会让执行文件大小增加到将近3倍。

     在ELF不同的文件型态里,ELF定义的信息该有的都有,header section……只是里面的值或有不同而已。

     Unix/Linux通常从一个_start函数开始而不是从main开始,_start后来会调用main,所以如果要精简程序,就不要用gcc编译,直接汇编用_start就可以了(^_^)。另外像section header table如果不需要做链接也可以不要,还有可执行文件的symbol table等,其实这些可以全部不要,不过要用汇编并同GAS来生成可执行文件。其实还有很多东西,这就是为什么即使根本没有调用任何函数,做成的动态文件,用ldd看一定有ld-linux.so libc.so了。

     而一个存在内存中的process image,如下所示:
ELF header
program header table
segment 0
segment 1
segment 2
segment ...
segment n
section header table (可以不要)

     Segment有Text,Data等,根据OS定义不同,Text根据存在硬盘文件里的.txt .fini等section来的,Data段根据.data .bss等section来的,一个segment通常包含了 一个或一个以上的section,这些section在程序员角度来看更显的重要。

     在支持ELF的系统上,一个程序是由可执行文件或者加上一些shared obj文件组成。为了执行这样的程序,系统使用那些文件创建进程的内存映像。为了使一个ELF文件装载到内存,必须有一个program header table(该program header table 是一个描述段信息的结构数组和一些为程序运行准备的信息)。这里有几个在ELF文档中定义的比较特别的sections。以下这些是对程序特别有用的:

.fini
    保存进程终止代码指令
    因此,当一个程序正常退出时,系统安排执行这个section中的代码
.init
    保存可执行指令,它构成了进程的初始化代码
    因此,当一个程序开始运行时,在main函数被调用前(C语言称为main),
系统安排执行这个section中的代码

     .init和.fini sections的存在有着特别的目的。假如一个函数放到.init section,在main函数执行前系统就会执行它。同理,假如一个函数放到.fini section,在main函数返回后该函数就会执行。该特性被C++编译器使用,完成全局的构造和析构函数功能。

     当ELF可执行文件被执行,系统将在把控制权交给可执行文件前装载所以相关的共享object文件。构造正确的.init和.fini sections,构造函数和析构函数将以正确的次序被调用。

     Unix/Linux的虚拟内存使用有这样的范围:

user area

0x0 ~ 0x0bffffff  -> 3GB

kernel area

0x0c000000 ~ 0xffffffff  -> 1GB

以下面程序代码为例:
int global;

static int func1 (void)
{
               static int b;
               int *c;
               int d;
               func2();
               return 1;
}
int func2 (void)
{
               int c;
               static int d;
               return 2;
}
int main(void)
{
               int a;
               static int b;
               int init = 3;
               func1();
               return 3;
}

那么从一个Linux执行文件在内存中看起来是这个样子:

i386 Linux的执行image

           Virtual   Address  Allocation

             |----------------------------------|0x0  
             | |-----------------------------|  |
             | |                                     |  |
             | |  Thread  stack              |  |  
             | |------------------------------|  |      
             |                                           |
             | |------------------------------|  |0x08048000 Text                          
             | |  executable                  |  |                    Data            
             | |                                      |  |                     ……
             | |                                      |  |
             | |                                      |  |
             | |                                      |  |
             | |------------------------------|  |
             |                                           |
             | |------------------------------|  |0x40000000 ld-linux.so
             | |                                     |  |                     libm.so
             | |  shared    LIB               |  |                     libc.so
             | |                                     |  |          
             | |  Stack                           |  |
             | |                                     |  |
       3GB| |----------------------------- |  |
             |                                           |
             | |------------------------------|  |0xc0000000
             | |                                      |  |
             | | Kernel Code and Data  |  |
             | |                                      |  |
             | |-------------------------------|  |
       4GB|---------------------------------   |0xffffffff

其中0x08048000 ~ 0x40000000 ~ 0xc0000000是这样存在的。

从C角度看的image:

      0x08048000
    |--------------------------------------------------------|
    |   |--------------------------------------------------|  |
    |   |   main()                                                 |  |                              
    |   |           xxxx                    Text                 |  |
    |   |   func1                           (instrction)   |  |  
    |   |           xxxx                                            |  |
    |   |   func2                                                  |  |  
    |   |           xxxx                                           |  |
    |   |-------------------------------------------------|  |
    |                                                                     |
    |   |-------------------------------------------------|  |
    |   |   int global                       Data             |  |
    |   |   static int b(main)  static int b(func1)  |  |
    |   |   static int c(func2)                               |  |
    |   |-------------------------------------------------|  |
    |                                                                     |
    |   |-------------------------------------------------|  |
    |   |   malloc(int)                      Heap            |  |
    |   |-------------------------------------------------|  |
    |                      |                                              |    
    |                      |                                              |
    |                     /|/                                             |                            
    |--------------------------------------------------------|
    |    0x40000000                                              |
    |                                                                      |
    |                                                                      |
    |--------------------------------------------------------|
    |                     /|/                                             |
    |                      |                                               |
    |                      |                                               |
    |    |-------------------------------------------------|  |
    |    |  func2 int c                     Stack  2          |  |
    |    |-------------------------------------------------|  |
    |                                                                      |
    |    |-------------------------------------------------|  |
    |    |  func1 int b                     Stack  1         |  |
    |    |-------------------------------------------------|  |
    |                                                                      |
    |    |-------------------------------------------------|  |
    |    |  main()  argv[0]  argv[1]  …                  |  |
    |    |-------------------------------------------------|  |
    |--------------------------------------------------------|
      0xbfffffff

      所以可以清楚的知道不同变量(global,static or auto)的生命周期(storage class),和不同变量的有效范围(scope)。
 
      Kernel code和data当然存在内存中,所以实际上都还要经过page table 转成实际地址。在0x0~ 0xbfffffff中的page table,每个process有不同page table,但在0xc0000000以下的page table,则都一样。

相关文章推荐

gcc与obj文件,动态链接文件和ELF文件

1、obj文件       程序员编写程序,其实就是编写出一个2进制(binary)文件。假如我们声明一个变量char c,也就是声明需要一个8bit的空间,那么就需要向系统声明豫留8bit的空间,...
  • ruglcc
  • ruglcc
  • 2012年08月01日 10:27
  • 1811

gcc与obj文件,动态链接文件和ELF文件

1、obj文件       程序员编写程序,其实就是编写出一个2进制(binary)文件。假如我们声明一个变量char c,也就是声明需要一个8bit的空间,那么就需要向系统声明豫留8bit的空间,...
  • wshn13
  • wshn13
  • 2012年05月07日 10:34
  • 897

gcc与obj文件,动态链接文件和ELF文件

、obj文件       程序员编写程序,其实就是编写出一个2进制(binary)文件。假如我们声明一个变量char c,也就是声明需要一个8bit的空间,那么就需要向系统声明豫留8bit的空间,...

Linux中ELF文件动态链接的加载

转自:http://www.ibm.com/developerworks/cn/linux/l-elf/part1/index.html 动态链接,一个经常被人提起的话题。但在这方面很少有文章来阐明...

ELF文件的加载和动态链接过程

近段时间在研究Erlang核心特性的实现,也许过段时间会有个系列的总结,期待... 今天看到有人写一个深入Hello World的文章,想起来读研的时候做的一个关于程序加载和链接的课程设计,也是以H...

(转)ELF文件的加载和动态链接过程

http://jzhihui.iteye.com/blog/1447570 近段时间在研究Erlang核心特性的实现,也许过段时间会有个系列的总结,期待...   今天看...

ELF文件的加载和动态链接过程

近段时间在研究Erlang核心特性的实现,也许过段时间会有个系列的总结,期待...   今天看到有人写一个深入Hello World的文章,想起来读研的时候做的一个关于程序加载和链接的课程设计,也...
  • raiet
  • raiet
  • 2013年08月29日 15:20
  • 679

Intel平台下Linux中ELF文件动态链接的加载、解析及实例分析

动态链接,一个经常被人提起的话题。但在这方面很少有文章来阐明这个重要的软件运行机制,只有一些关于动态链接库编程的文章。本系列文章就是要从动态链接库源代码的层次来探讨这个问题。 当然从文章的题目就...
  • zwx5225
  • zwx5225
  • 2011年10月02日 15:25
  • 281

Linux下ELF格式可执行文件及动态链接相关部分的解析

Linux下面的ELF文件主要由ELF头、程序头和各个段组成。 本文使用的示例程序如下。首先把它编译为可执行文件,再使用Linux下面的hexdump命令,把可执行文件完全转换为16进制的表示形式,然...

Intel平台下Linux中ELF文件动态链接的加载、解析及实例分析(一): 加载

From:http://www.ibm.com/developerworks/cn/linux/l-elf/part1/ 当然从文章的题目就可以看出,intel平台下的linux ELF文件的动...
内容举报
返回顶部
收藏助手
不良信息举报
您举报文章:(转载)GCC与Obj文件,动态链接文件和ELF文件
举报原因:
原因补充:

(最多只允许输入30个字)