從程序員角度看ELF

原文:《 ELF:From The Programmer's Perspective》

作者：Hongjiu Lu <mailto: hjl@nynexst.com>
NYNEX Science & Technology, Inc.
500 Westchester Avenue
White Plains, NY 10604, USA

翻譯：alert7 <mailto: alert7@21cn.com
????????????????????? alert7@xfocus.org
???????????? >

主頁: http://www.xfocus.org
時間: 2001-9-10


★概要：

這片文檔從程序員的角度討論了linux的ELF二進制格式。介紹了一些ELF執行
文件在運行控制的技術。展示了如何使用動態連接器和如何動態裝載ELF。
我們也演示了如何在LINUX使用GNU C/C++編譯器和一些其他工具來創建共享的
C/C++庫。

★1前言

最初，UNIX系統實驗室(USL)開發和發布了Executable and linking Format
(ELF)這樣的二進制格式。在SVR4和Solaris 2.x上，都做為可執行文件默認的
二進制格式。ELF比a.out和COFF更強大更靈活。結合一些適當的工具，程序員
使用ELF就可以在運行時控制程序的流程。


★2 ELF類型

三種主要的ELF文件類型：

.可執行文件：包含了代碼和數據。具有可執行的程序。
例如這樣一個程序

# file dltest
dltest: ELF 32-bit LSB executable, Intel 80386, version 1,
dynamically linked (uses shared libs), not stripped

.可重定位文件：包含了代碼和數據（這些數據是和其他重定位文件和共享的
object文件一起連接時使用的）
例如這樣文件

# file libfoo.o
libfoo.o: ELF 32-bit LSB relocatable, Intel 80386, version 1,
?? not stripped

.共享boject文件（又可叫做共享庫）：包含了代碼和數據（這些數據是在連接
時候被連接器ld和運行時動態連接器使用的）。動態連接器可能稱為
ld.so.1,libc.so.1 或者 ld-linux.so.1。
例如這樣文件

# file libfoo.so
libfoo.so: ELF 32-bit LSB shared object, Intel 80386, version
1, not stripped

ELF section部分是非常有用的。使用一些正確的工具和技術，程序員就能
熟練的操作可執行文件的執行。

★3 .init和.fini sections

在ELF系統上，一個程序是由可執行文件或者還加上一些共享object文件組成。
為了執行這樣的程序，系統使用那些文件創建進程的內存映象。進程映象
有一些段(segment),包含了可執行指令，數據，等等。為了使一個ELF文件
裝載到內存，必須有一個program header(該program header是一個描述段
信息的結構數組和一些為程序運行準備的信息)。

一個段可能有多個section組成.這些section在程序員角度來看更顯的重要。

每個可執行文件或者是共享object文件一般包含一個section table,該表
是描述ELF文件里sections的結構數組。這里有幾個在ELF文檔中定義的比較
特別的sections.以下這些是對程序特別有用的：

.fini
該section保存著進程終止代碼指令。因此，當一個程序正常退出時，
系統安排執行這個section的中的代碼。
.init
該section保存著可執行指令，它構成了進程的初始化代碼。
因此，當一個程序開始運行時，在main函數被調用之前(c語言稱為
main)，系統安排執行這個section的中的代碼。

.init和.fini sections的存在有著特別的目的。假如一個函數放到
.init section，在main函數執行前系統就會執行它。同理，假如一
個函數放到.fini section，在main函數返回后該函數就會執行。
該特性被C++編譯器使用，完成全局的構造和析構函數功能。

當ELF可執行文件被執行，系統將在把控制權交給可執行文件前裝載所以相關
的共享object文件。構造正確的.init和.fini sections,構造函數和析構函數
將以正確的次序被調用。

★3.1 在c++中全局的構造函數和析構函數

在c++中全局的構造函數和析構函數必須非常小心的處理碰到的語言規范問題。
構造函數必須在main函數之前被調用。析構函數必須在main函數返回之后
被調用。例如，除了一般的兩個輔助啟動文件crti.o和crtn.o外，GNU C/C++
編譯器--gcc還提供兩個輔助啟動文件一個稱為crtbegin.o，還有一個被稱為
crtend.o。結合.ctors和.dtors兩個section，c++全局的構造函數和析構函數
能以運行時最小的負載，正確的順序執行。


.ctors
該section保存著程序的全局的構造函數的指針數組。

.dtors
該section保存著程序的全局的析構函數的指針數組。

ctrbegin.o
有四個section:
1 .ctors section
local標號__CTOR_LIST__指向全局構造函數的指針數組頭。在
ctrbegin.o中的該數組只有一個dummy元素。

[譯注：
# objdump -s -j .ctors
/usr/lib/gcc-lib/i386-redhat-linux/egcs-2.91.66/crtbegin.o

/usr/lib/gcc-lib/i386-redhat-linux/egcs-2.91.66/crtbegin.o:
file format elf32-i386
Contents of section .ctors:
0000 ffffffff???????????????????????????? ....
這里說的dummy元素應該就是指的是ffffffff
]

2 .dtors section
local標號__DTOR_LIST__指向全局析構函數的指針數組頭。在
ctrbegin.o中的該數組僅有也只有一個dummy元素。

3 .text section
只包含了__do_global_dtors_aux函數,該函數遍歷__DTOR_LIST__
列表，調用列表中的每個析構函數。
函數如下：

Disassembly of section .text:

00000000 <__do_global_dtors_aux>:
?? 0:?? 55????????????????????? push?? %ebp
?? 1:?? 89 e5?????????????????? mov??? %esp,%ebp
?? 3:?? 83 3d 04 00 00 00 00??? cmpl?? $0x0,0x4
?? a:?? 75 38?????????????????? jne??? 44 <__do_global_dtors_aux+0x44>
?? c:?? eb 0f?????????????????? jmp??? 1d <__do_global_dtors_aux+0x1d>
?? e:?? 89 f6?????????????????? mov??? %esi,%esi
? 10:?? 8d 50 04??????????????? lea??? 0x4(%eax),%edx
? 13:?? 89 15 00 00 00 00?????? mov??? %edx,0x0
? 19:?? 8b 00?????????????????? mov??? (%eax),%eax
? 1b:?? ff d0?????????????????? call?? *%eax
? 1d:?? a1 00 00 00 00????????? mov??? 0x0,%eax
? 22:?? 83 38 00??????????????? cmpl?? $0x0,(%eax)
? 25:?? 75 e9?????????????????? jne??? 10 <__do_global_dtors_aux+0x10>
? 27:?? b8 00 00 00 00????????? mov??? $0x0,%eax
? 2c:?? 85 c0?????????????????? test?? %eax,%eax
? 2e:?? 74 0a?????????????????? je???? 3a <__do_global_dtors_aux+0x3a>
? 30:?? 68 00 00 00 00????????? push?? $0x0
? 35:?? e8 fc ff ff ff????????? call?? 36 <__do_global_dtors_aux+0x36>
? 3a:?? c7 05 04 00 00 00 01??? movl?? $0x1,0x4
? 41:?? 00 00 00
? 44:?? c9????????????????????? leave
? 45:?? c3????????????????????? ret
? 46:?? 89 f6?????????????????? mov??? %esi,%esi


4 .fini section
它只包含一個__do_global_dtors_aux的函數調用。請記住，它僅是
一個函數調用而不返回的，因為crtbegin.o的.fini section是這個
函數體的一部分。
函數如下：
Disassembly of section .fini:

00000000 <.fini>:
?? 0:?? e8 fc ff ff ff????????? call?? 1 <.fini+0x1>


crtend.o
也有四個section:

1 .ctors section
local標號__CTOR_END__指向全局構造函數的指針數組尾部。

2 .dtors section
local標號__DTOR_END__指向全局析構函數的指針數組尾部。

3 .text section
只包含了__do_global_ctors_aux函數,該函數遍歷__CTOR_LIST__
列表，調用列表中的每個構造函數。
函數如下：
00000000 <__do_global_ctors_aux>:
?? 0:?? 55????????????????????? push?? %ebp
?? 1:?? 89 e5?????????????????? mov??? %esp,%ebp
?? 3:?? 53????????????????????? push?? %ebx
?? 4:?? bb fc ff ff ff????????? mov??? $0xfffffffc,%ebx
?? 9:?? 83 3d fc ff ff ff ff??? cmpl?? $0xffffffff,0xfffffffc
? 10:?? 74 0c?????????????????? je???? 1e <__do_global_ctors_aux+0x1e>
? 12:?? 8b 03?????????????????? mov??? (%ebx),%eax
? 14:?? ff d0?????????????????? call?? *%eax
? 16:?? 83 c3 fc??????????????? add??? $0xfffffffc,%ebx
? 19:?? 83 3b ff??????????????? cmpl?? $0xffffffff,(%ebx)
? 1c:?? 75 f4?????????????????? jne??? 12 <__do_global_ctors_aux+0x12>
? 1e:?? 8b 5d fc??????????????? mov??? 0xfffffffc(%ebp),%ebx
? 21:?? c9????????????????????? leave
? 22:?? c3????????????????????? ret
? 23:?? 90????????????????????? nop

4 .init section
它只包含一個__do_global_ctors_aux的函數調用。請記住，它僅是
一個函數調用而不返回的，因為crtend.o的.init section是這個函
數體的一部分。
函數如下：
Disassembly of section .init:

00000000 <.init>:
?? 0:?? e8 fc ff ff ff????????? call?? 1 <.init+0x1>


crti.o
在.init section中僅是個_init的函數標號。
在.fini section中的_fini函數標號。

crtn.o
在.init和.fini section中僅是返回指令。

Disassembly of section .init:

00000000 <.init>:
?? 0:?? 8b 5d fc??????????????? mov??? 0xfffffffc(%ebp),%ebx
?? 3:?? c9????????????????????? leave
?? 4:?? c3????????????????????? ret
Disassembly of section .fini:

00000000 <.fini>:
?? 0:?? 8b 5d fc??????????????? mov??? 0xfffffffc(%ebp),%ebx
?? 3:?? c9????????????????????? leave
?? 4:?? c3????????????????????? ret

編譯產生可重定位文件時，gcc把每個全局構造函數掛在__CTOR_LIST上
（通過把指向構造函數的指針放到.ctors section中）。
它也把每個全局析構函掛在__DTOR_LIST上（通過把指向析構函的指針
放到.dtors section中）。

連接時，gcc在所有重定位文件前處理crtbegin.o,在所有重定位文件后處理
crtend.o。另外，crti.o在crtbegin.o之前被處理，crtn.o在crtend.o之后
被處理。

當產生可執行文件時，連接器ld分別的連接所有可重定位文件的ctors 和
.dtors section到__CTOR_LIST__和__DTOR_LIST__列表中。.init section
由所有的可重定位文件中_init函數組成。.fini由_fini函數組成。

運行時，系統將在main函數之前執行_init函數，在main函數返回后執行
_fini函數。


★4 ELF的動態連接與裝載

★4.1 動態連接

當在UNIX系統下，用C編譯器把C源代碼編譯成可執行文件時，c編譯驅動器一般
將調用C的預處理，編譯器，匯編器和連接器。

. c編譯驅動器首先把C源代碼傳到C的預處理器，它以處理過的宏和
指示器形式輸出純C語言代碼。

. c編譯器把處理過的C語言代碼翻譯為機器相關的匯編代碼。

. 匯編器把結果的匯編語言代碼翻譯成目標的機器指令。結果這些
機器指令就被存儲成指定的二進制文件格式，在這里，我們使用的
ELF格式。

. 最后的階段，連接器連接所有的object文件，加入所有的啟動代碼和
在程序中引用的庫函數。

下面有兩種方法使用lib庫

--static library
一個集合，包含了那些object文件中包含的library例程和數據。用
該方法，連接時連接器將產生一個獨立的object文件(這些
object文件保存著程序所要引用的函數和數據)的copy。

--shared library
是共享文件，它包含了函數和數據。用這樣連接出來的程序僅在可執行
程序中存儲著共享庫的名字和一些程序引用到的標號。在運行時，動態
連接器（在ELF中也叫做程序解釋器）將把共享庫映象到進程的虛擬
地址空間里去，通過名字解析在共享庫中的標號。該處理過程也稱為
動態連接(dynamic linking)

程序員不需要知道動態連接時用到的共享庫做什么，每件事情對程序員都是
透明的。


★4.2 動態裝載(Dynamic Loading)

動態裝載是這樣一個過程：把共享庫放到執行時進程的地址空間，在庫中查找
函數的地址，然后調用那個函數，當不再需要的時候，卸載共享庫。它的執行
過程作為動態連接的服務接口。

在ELF下，程序接口通常在<dlfcn.h>中被定義。如下：

void *dlopen(const char * filename,int flag);
const char * dlerror(void);
const void * dlsym (void handle*,const char * symbol);
int dlclose(void * handle);

這些函數包含在libdl.so中。下面是個例子，展示動態裝載是如何工作的。
主程序在運行時動態的裝載共享庫。一方面可指出哪個共享庫被使用，哪個
函數被調用。一方面也能在訪問共享庫中的數據。

[alert7@redhat62 dl]# cat dltest.c
#include <stdio.h>
#include <stdlib.h>
#include <getopt.h>
#include <dlfcn.h>
#include <ctype.h>

typedef void (*func_t) (const char *);

void dltest(const char *s)
{
printf("From dltest:");
for (;*s;s++)
{
putchar(toupper(*s));
}
putchar('/n');
}

main(int argc,char **argv)
{
void *handle;
func_t fptr;
char * libname = "./libfoo.so";
char **name=NULL;
char *funcname = "foo";
char *param= "Dynamic Loading Test";
int ch;
int mode=RTLD_LAZY;

while ((ch = getopt(argc,argv,"a:b:f:l:"))!=EOF)
{
switch(ch)
{
case 'a':/*argument*/
param=optarg;
break;
case 'b':/*how to bind*/
switch(*optarg)
{
case 'l':/*lazy*/
mode = RTLD_LAZY;
break;
case 'n':/*now*/
mode = RTLD_NOW;
break;
}
break;
case 'l':/*which shared library*/
libname= optarg;
break;
case 'f':/*which function*/
funcname= optarg;
}
?? }

handle = dlopen(libname,mode);
if (handle ==NULL)
{
fprintf(stderr,"%s:dlopen:'%s'/n",libname,dlerror());
exit(1);
}

fptr=(func_t)dlsym(handle,funcname);
if (fptr==NULL)
{
fprintf(stderr,"%s:dlsym:'%s'/n",funcname,dlerror());
exit(1);
}


name = (char **) dlsym(handle,"libname");
if (name==NULL)
{
fprintf(stderr,"%s:dlsym:'libname'/n",dlerror());
exit(1);
}

printf("Call '%s' in '%s':/n",funcname,*name);

/*call that function with 'param'*/
(*fptr)(param);

dlclose(handle);
return 0;

}

這里有兩個共享庫，一個是libfoo.so一個是libbar.so。每個都用同樣的全局
字符串變量libname,分別各自有foo和bar函數。通過dlsym，對程序來說,他們
都是可用的。

[alert7@redhat62 dl]# cat libbar.c
#include <stdio.h>

extern void dltest(const char *);
const char * const libname = "libbar.so";

void bar (const char *s)
{
dltest("Called from libbar.");
printf("libbar:%s/n",s);
}


[alert7@redhat62 dl]# cat libfoo.c
#include <stdio.h>

extern void dltest (const char *s);
const char *const libname="libfoo.so";

void foo(const char *s)
{
const char *saved=s;

dltest("Called from libfoo");
printf("libfoo:");
for (;*s;s++);
for (s--;s>=saved;s--)
{
putchar (*s);
}
putchar ('/n');
}

使用Makefile文件來編譯共享庫和主程序是很有用的。因為libbar.so和
libfoo.so也調用了主程序里的dltest函數。

[alert7@redhat62 dl] #cat Makefile
CC=gcc
LDFLAGS=-rdynamic
SHLDFLAGS=
RM=rm

all:dltest

libfoo.o:libfoo.c
$(CC) -c -fPIC $<

libfoo.so:libfoo.o
$(CC) $(SHLDFLAGS) -shared -o $@ $^

libbar: libbar.c
$(CC) -c -fPIC $<

libbar.so:libbar.o
$(CC) $(SHLDFLAGS) -shared -o $@ $^

dltest: dltest.o libbar.so libfoo.so
$(CC) $(LDFLAGS) -o $@ dltest.o -ldl

clean:
$(RM) *.o *.so dltest

處理流程：

[alert7@redhat62 dl]# export ELF_LD_LIBRARY_PATH=.
[alert7@redhat62 dl]# ./dltest
Call 'foo' in 'libfoo.so':
From dltest:CALLED FROM LIBFOO
libfoo:tseT gnidaoL cimanyD
[alert7@redhat62 dl]# ./dltest -f bar
bar:dlsym:'./libfoo.so: undefined symbol: bar'
[alert7@redhat62 dl]# ./dltest -f bar -l ./libbar.so
Call 'bar' in 'libbar.so':
From dltest:CALLED FROM LIBBAR.
libbar:Dynamic Loading Test


在動態裝載進程中調用的第一個函數就是dlopen,它使得共享可庫對
運行著的進程可用。dlopen返回一個handle,該handle被后面的dlsym
和dlclose函數使用。dlopen的參數為NULL有特殊的意思---它使得在
程序導出的標號和當前已經裝載進內存的共享庫導出的標號通過dlsym
就可利用。

在一個共享庫已經裝載進運行著的進程的地址空間后，dlsym可用來
獲得在共享庫中導出的標號地址。然后就可以通過dlsym返回的地址
來訪問里面的函數和數據。

當一個共享庫不再需要使用的時候，就可以調用dlclose卸載該函數庫。
假如共享庫在啟動時刻或者是通過其他的dlopen調用被裝載的話，該
共享庫不會從調用的進程的地址空間被移走。

假如dlclose操作成功，返回為0。dlopen和dlsym如果有錯誤，將返回
為NULL。為了獲取診斷信息，可調用dlerror.


★5 支持ELF的LINUX上的編譯器GNU GCC

感謝Eric Youngdale (eric@aib.com),lan Lance Taylor (ian@cygnus.com)
還有許多為gcc支持ELF功能的默默做貢獻的人。我們能用gcc和GNU的二進制
工具很容易的創建ELF可執行文件和共享庫。

★5.1 共享C庫 Shared C Library

在ELF下構造一個共享庫比其他的容易的多。但是需要編譯器，匯編器，
連接器的支持。首先，需要產生位置無關(position-independent)代碼。
要做到這一點，gcc需要加上編譯選項-fPIC
[alert7@redhat62 dl]# gcc -fPIC -O -c libbar.c

這時候就適合構造共享庫了，加上-shared編譯選項
[alert7@redhat62 dl]# gcc -shared -o libbar.so libbar.o

現在我們構造的libbar.so就可以被連接器(link editor)和動態連接器
(dynamic linker)。只要編譯時帶上-fPIC編譯選項,可以把許多重定位
文件加到共享庫中。為了把baz.o和共享庫連接在一起，可以如下操作：
# gcc -O -c baz.c
# gcc -o baz baz.o -L. -lbar

在把libbar.so安裝到動態連接器能找到的正確位置上之后，運行baz將
使libbar.so映象到baz的進程地址空間。內存中libbar.so的一份拷貝將
被所有的可執行文件(這些可執行程序連接時和它一塊兒連接的或者
在運行時動態裝載的)共享。

★5.2 共享C++庫 Shared C++ Library

在共享c++庫中主要的困難是如何對待構造函數和析構函數。
在SunOS下，構造和使用一個共享的ELF C庫是容易的，但是在SunOS下不能
構造共享的C++庫，因為構造函數和析構函數有特別的需求。為止，在ELF
中的.init和.init section提供了完美的解決方法。

當構造共享C++庫時，我們使用crtbegin.o和crtend.o這兩個特殊的版本，
(它們已經是經過-fPIC的)。對于連接器(link editor)來說，構造共享
的C++庫幾乎是和一般的可執行文件一樣的。全局的構造函數和析構函數
被.init和.fini section處理(在上面3.1節中已經討論過)。

但一個共享庫被映射到進程的地址空間時，動態連接器將在傳控制權給程序
之前執行_init函數，并且將為_fini函數安排在共享庫不再需要的時候被
執行。

連接選項-shared是告訴gcc以正確的順序放置必要的輔助文件并且告訴它將
產生一個共享庫。-v選項將顯示什么文件什么選項被傳到了連接器
(link editor).

[alert7@redhat62 dl]# gcc -v -shared -o libbar.so libbar.o
Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/egcs-2.91.66/specs
gcc version egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)
/usr/lib/gcc-lib/i386-redhat-linux/egcs-2.91.66/collect2 -m elf_i386
-shared -o libbar.so /usr/lib/crti.o /usr/lib/gcc-lib/i386-redhat
-linux/egcs-2.91.66/crtbeginS.o
-L/usr/lib/gcc-lib/i386-redhat-linux/egcs-2.91.66
-L/usr/i386-redhat-linux/lib libbar.o -lgcc -lc --version-script
/usr/lib/gcc-lib/i386-redhat-linux/egcs-2.91.66/libgcc.map
-lgcc /usr/lib/gcc-lib/i386-redhat-linux/egcs-2.91.66/crtendS.o
/usr/lib/crtn.o

crtbeginS.o和crtendS.o用-fPIC編譯的兩個特殊的版本。帶上-shared
創建共享庫是重要的，因為那些輔助的文件也提供其他服務。我們將在
5.3節中討論。

★5.3 擴展的GCC特性

GCC有許多擴展的特性。有些對ELF特別的有用。其中一個就是__attribute__。
使用__attribute__可以使一個函數放到__CTOR_LIST__或者__DTOR_LIST__里。
例如：

[alert7@redhat62 dl]# cat miss.c

#include <stdio.h>
#include <stdlib.h>

static void foo(void) __attribute__ ((constructor));
static void bar(void) __attribute__ ((destructor));


int main(int argc, char *argv[])
{
??????? printf("foo == %p/n", foo);
??????? printf("bar == %p/n", bar);

??????? exit(EXIT_SUCCESS);
}

void foo(void)
{
??????? printf("hi dear njlily!/n");
}

void bar(void)
{
??????? printf("missing u! goodbye!/n");
}

[alert7@redhat62 dl]# gcc -o miss miss.c
[alert7@redhat62 dl]# ./miss
hi dear njlily!
foo == 0x8048434
bar == 0x8048448
missing u! goodbye!

我們來看看是否加到了.ctors和.dtors中。
[alert7@redhat62 dl]# objdump -s -j .ctors miss

miss:???? file format elf32-i386

Contents of section .ctors:
8049504 ffffffff 34840408 00000000?????????? ....4.......

[alert7@redhat62 dl]# objdump -s -j .dtors miss

miss:???? file format elf32-i386

Contents of section .dtors:
8049510 ffffffff 48840408 00000000?????????? ....H.......

已經把foo和bar地址分別放到了.ctors和.dors，顯示34840408只是因為
x86上是LSB編碼的，小端序。

__attribute__ ((constructor))促使函數foo在進入main之前會被自動調用。
__attribute__ ((destructor))促使函數bar在main返回或者exit調用之后
會被自動調用。foo和bar必須是不能帶參數的而且必須是static void類型的
函數。在ELF下，這個特性在一般的可執行文件和共享庫中都能很好的工作。


我們也可以創建自己的section,在這里我創建了一個alert7 section.
[alert7@redhat62 dl]# cat test.c
#include <stdio.h>
#include <stdlib.h>

static void foo(void) __attribute__ ((section ("alert7")));
static void bar(void) __attribute__ ((section ("alert7")));


int main(int argc, char *argv[])
{
??????? foo();

??????? printf("foo == %p/n", foo);
??????? printf("bar == %p/n", bar);
??????? bar();
??????? exit(EXIT_SUCCESS);
}

void foo(void)
{
??????? printf("hi dear njlily!/n");
}
void bar(void)
{
??????? printf("missing u! goodbye!/n");
}
[alert7@redhat62 dl]# gcc -o test test.c
[alert7@redhat62 dl]# ./test
hi dear njlily!
foo == 0x804847c
bar == 0x8048490
missing u! goodbye!

[alert7@redhat62 dl]# objdump -x test
....
Sections:
Idx Name????????? Size????? VMA?????? LMA?????? File off? Algn
? 0 .interp?????? 00000013? 080480f4? 080480f4? 000000f4? 2**0
????????????????? CONTENTS, ALLOC, LOAD, READONLY, DATA
...
12 alert7??????? 00000026? 0804847c? 0804847c? 0000047c? 2**2
????????????????? CONTENTS, ALLOC, LOAD, READONLY, CODE
...

[alert7@redhat62 dl]# objdump -D test
Disassembly of section alert7:

0804847c <foo>:
804847c:?????? 55????????????????????? push?? %ebp
804847d:?????? 89 e5?????????????????? mov??? %esp,%ebp
804847f:?????? 68 de 84 04 08????????? push?? $0x80484de
8048484:?????? e8 a3 fe ff ff????????? call?? 804832c <_init+0x70>
8048489:?????? 83 c4 04??????????????? add??? $0x4,%esp
804848c:?????? c9????????????????????? leave
804848d:?????? c3????????????????????? ret
804848e:?????? 89 f6?????????????????? mov??? %esi,%esi

08048490 <bar>:
8048490:?????? 55????????????????????? push?? %ebp
8048491:?????? 89 e5?????????????????? mov??? %esp,%ebp
8048493:?????? 68 ef 84 04 08????????? push?? $0x80484ef
8048498:?????? e8 8f fe ff ff????????? call?? 804832c <_init+0x70>
804849d:?????? 83 c4 04??????????????? add??? $0x4,%esp
80484a0:?????? c9????????????????????? leave
80484a1:?????? c3????????????????????? ret

在這里，我創建了一個自己的alert7 section,并把foo,bar兩個函數放到了這個
section中。一般定義的函數都會放在.text section中。



★5.3.1 在C庫中的初始化函數

另外一個GCC的特性是__attribute__( section ("sectionname") ).使用這個，
能把一個函數或者是數據結構放到任何的section中。

static void
foo (int argc,char **argc,char **envp)
__attribute__ ((section ("_libc_foo")));

static void
foo (int argc,char **argv,char **envp)
{
}

static void
bar (int argc,char **argv,char **envp)
{
}

static void * __libc_subinit_bar__
__attribute__ (( section ("_libc_subinit")))=&(bar);

這里，我們把foo放到了_libc_foo section，把__libc_subinit_bar__放
到了_libc_subinit section中。在Linux C庫中，_libc_subinit 是一個特別
的section，它包含了一個函數指針（有如下原型）的數組。

void (*) (int argc,char **argv,char **envp);

這里的argc,argv,envp跟在main中的有同樣的意義。該section中的函數在進入
main函數之前就會被調用。這是很有用的，可用來在Linux C庫中初始化一些
全局變量。

[譯注：_libc_subinit section真有這個特別的功能嗎？我是沒有試
成功，如果有人試成功或者認為我理解有誤的地方，千萬記得mail給
我:)
測試程序如下：
#include <stdio.h>
#include <stdlib.h>
static void foo(int argc,char **argv,char **envp)
{
printf("hi dear njlily!/n");
}

int main(int argc, char *argv[])
{
??????? printf("foo == %p/n", foo);
??????? exit(EXIT_SUCCESS);
}

static void * __libc_subinit_bar__
??????? __attribute__ (( section ("_libc_subinit")))=&(foo);

[alert7@redhat62 dl]# gcc -o test1 test1.c
[alert7@redhat62 dl]# ./test1
foo == 0x8048400
:( 用objdump，顯示已經創建了一個_libc_subinit section,并且
該section前四個字節就是foo地址0x8048400

]



★5.4 利用GCC和GNU ld

這一些命令行的選項對GCC和GNU ld創建ELF時特別有用。-shared告訴gcc
產生一個共享庫，該共享庫能在連接時和其他的共享文件一起形成可執行
文件，該共享庫也能在運行時裝載進可執行文件的地址空間。使用-shared
是創建一個共享ELF庫的首選方法。

另外一個有用的命令行選項是-Wl,ldoption,傳遞參數ldoption作為連接器
的選項。假如ldoption包含多個逗號，將分離成多個選項。

-static選項將產生一個和static庫一道連接的可執行文件。當沒有開啟
-static選項時，連接器首先試著用共享庫，假如共享版本不可用，然后
再試著用靜態(static)庫。

這里還有些特別的命令行選項對ELF來說特別的或者說是有用的。

-dynamic-linker file
設置動態連接器(dynamic linker)的名字。默認的動態連接器
或者是/usr/lib/libc.so.1或者是/usr/lib/libd1.so.1


-export-dynamic
告訴連接器使在可執行文件中的所有標號對動態連接器可用。當一個
動態裝載進的共享庫參考可執行文件中的標號，該標號一般在動態連
接時是不可用時，這時候就特別有用。

-lfile
加文件到需要連接的列表中。該選項可用在許多時候。ld將搜索它的
path-list查找文件libfile.so(也就是說假如庫為libbar.so，那么
使用的時候就這樣使用，-lbar),或者libfile.a（static版本的）。
一些情況下，共享庫名libfile.so會被存儲在resulting executable
或者是共享庫中。當resulting executable或者是共享庫被裝載進內
存，動態連接器也將把使用記錄過的共享庫裝載到進程的地址空間去。
在以后的事情情況下，把必要的函數和數據被拷貝到可執行文件，減
少代碼長度。

-m emulation
仿效emulation連接器r.-V參數可列出所有可用的選項.

-M | -Map mapfile
把連接map輸出到標準輸出或者一個mapfile文件里，該連接map含有
關于標號被ld映象到了哪里的一些診斷信息，還有全局共同的存儲
分配信息。

-rpath directory
加一個目錄到運行時library的搜索路徑。所有的-rpath參數被連接
在一起然后傳給動態連接器。它們被用來在運行時定位共享庫。

-soname name
當創建一個共享庫時，指定的名字被放在共享庫中。當和這個共享
庫連接的可執行文件被運行，動態連接器將試著map記錄著的指定
名字的共享庫而不是傳給連接器的文件名。

-static
告訴連接器不要和任何共享庫連接。

-verbose
告訴連接器打印它每個要打開的文件名。

linux下gcc beta版本使用-dynamic-linker file選項設置動態連接器為
/lib/ld-linker.so.1。該選項可以使ELF和a.out共享庫很好的共存。

有件事情是另人感興趣的。

[alert7@redhat62 dl]# gcc -shared -o libbar.so libbar.o -lfoo

假如libfoo.so被用來創建共享庫時，有趣的時候就會發生了。當libbar.so
被映象到進程的地址空間的時候，動態連接器也把libfoo.so映象到內存。
假如libbar.so需要libfoo.so的時候，這個特性非常有用。實際上使用
libbars.o庫的程序編譯時是不需要-lfoo的。假如archive版本的libfoo.a
被使用，當在libbar.a中的標號被libbar.o引用時，它將會被搜索到。假使在
libbar.so中包含libfoo.a甚至它們根本不被libbar.o使用，在這樣的情況下
必須逐步把.o文件加到libbar.o中：

# rm -rf /tmp/foo
# mkdir /tmp/foo
# (cd /tmp/foo/;ar -x ....../libfoo.a)
# gcc -shared -o libbar.so libbar.o /tmp/foo/*.o
# rm -rf /tmp/foo

在libfoo.a中的.o文件必須用-fPIC編譯或者至少和PIC（位置無關）是
兼容的。

當使用

static void * __libc_subinit_bar__
__attribute__ ((section ("_libc_subinit")))=&(bar);

來把一個標號放到一個沒有被連接器定義的section中（在這里是
_libc_subinit).連接器將所有在_libc_subinit section中的標號共同
創建兩個標號，一個是__start__libc_subinit和__stop__libc_subinit,
它們作為C的標志符被使用。

警告：
下面是完全可能的：連接器可能不能搜索到包含_libc_subinit section
的文件(該section中沒有程序執行需要的標號)。這就使程序要確定使
_libc_subinit section能被連接器搜索得到。

一種解決的辦法是：把一個dummy標號放到_libc_subinit section中，
在文件中定義它，使它參考引用_libc_subinit section.


★5.5 Linux下的ELF

在Linux下ELF的執行有獨特的特性，這些特性對Linux的使用者來說是很有用
的。一些Linux自己的擴展跟Solaris ELF的執行很類似。

★5.5.1 ELF的宏(macros)

<gnu-stabs.h>中，定義了能維護標號的一些宏。

elf_alias(name1,name2)
為標號name1定義一個化名name2.當文件中標號名已經被定義的時候
應該是有很用的。

weak_alias(name1,name2)
為標號name1定義一個弱化名name2。僅當name2沒有在任何地方定義
時，連接器就會用name1解析name2相關的符號。在文件中定義的
標號name1也會同樣處理。

elf_set_element(set,symbol)
強迫標號成為set集合的元素。為每個set集合創建一個section.

symbol_set_declare(set)
在該模塊中宣告一個集合set.事實上宣告了兩個標號：
1? 一個set的開始標號
extern void * const __start_set
2? 一個set的結尾標號
extern void * const __stop_set

symbol_set_first_element(set)
返回一個指針(void * const *),指向set集合第一個元素。

symbol_set_end_p(set,ptr)
假如ptr(void * const *)逐漸增加指向set的最后一個元素，
就返回為true.

使用這些宏，程序員能任意從不同的源文件中創建列表。


★5.5.2 library(庫)的定位和搜索路徑

在Linux下，大部分系統的library庫被安裝在/usr/lib目錄下。只有一些
基本的共享庫被安裝在/lib目錄下。例如：libc.so,libcurses.so,libm.so
,libtermcap.so(各個版本對應的文件會有些不同)，在其他部分被mount上
之前，那些文件是啟動Linux系統所必須的。連接器默認的搜索路徑是
/lib,/usr/lib,/usr/local/lib,/usr/i486-linux/lib。

環境變量LD_LIBRARY_PATH也可保存目錄列表，用(:)分開，該變量被動態
連接器檢查并用該變量指出的目錄查找共享庫。
例如：/usr/X11R6/lib:/usr/local/lib:告訴動態連接器查找共享庫除了
現在在默認的目錄查找外，然后在/usr/X11R6/lib目錄，然后再是
/usr/local/lib目錄，然后再是當前目錄。

新的環境變量ELF_LD_LIBRARY_PATH扮演著和LD_LIBRARY_PATH類似的角色。
因為LD_LIBRARY_PATH也被老的a.out DLL linux的共享庫使用。為了避免
來自DLL連接器的不必要的警告，對于在Linux下ELF的動態連接器來說，
最好使用LD_LIBRARY_PATH環境變量。

另外一個特性是/etc/ld.so.conf文件，該文件包含了一些目錄列表。
例如：

/usr/X11R6/lib
/usr/lib
/usr/kerberos/lib
/usr/i486-linux-libc5/lib
/usr/lib/gconv
/usr/lib/qt-2.1.0/lib
/usr/lib/qt-1.45/lib

程序ldconfig將把/etc/ld.so.conf文件中列出的搜索目錄中的所有的
共享庫存儲到/etc/ld.so.cache中。假如共享庫已經被從默認的目錄中
移走，Linux ELF動態連接庫將在/etc/ld.so.cache文件中找該共享庫。



★5.5.3 共享庫的版本

在ELF系統上，假如兩個共享庫有同樣的應用程序二進制接口(ABI)的子集
的話,對那些僅僅使用那些ABI子集的程序來說，這兩個共享庫是可以互相
通用的（當然那兩個共享庫有同樣的函數功能）。

當一個庫被改變，只要新的ABI和前面一個版本的共享庫有100%的兼容的話，
所有和前面版本連接的程序在新的共享庫下也能很好的運行。為了支持這，
foo庫必須小心的維護：

1.這個共享庫應該如下構造：

[alert7@redhat62 dl]# gcc -shared -Wl,-soname,libfoo.so.major /
-o libfoo.so.major.minor.patch-level libfoo.o

動態連接器運行時將試著定位和映象libfoo.so.major而不管事實上用的共享
文件名libfoo.so.major.patch-level。

2.一個符號連接應該指向正確的共享庫

[alert7@redhat62 dl]# ln -s libfoo.so.major.minor.patch-level /
libfoo.so.major

3.當ABI改變和原來版本不兼容的時，主(major)版本號應該升級。

當搜索共享庫的時候，Linux連接器將使用最新的共享庫（它們有最高的
major,minor和patch level的版本號）。


★5.5.4 共享(shared)庫和靜態(static)庫的混合連接

默認情況下，假如共享庫可用，連接器會使用共享庫。但是-Bdynamic和
-Bstatic提供了很好控制庫的方法。它們可以決定用共享庫還是用靜態庫。

傳-Bdynamic和-Bstatic選項給連接器，如下操作：
# gcc -o main main.o -Wl,-Bstatic /
-lfoo -Wl,-Bdynamic -lbar

# gcc -o main main.o -Wl,-Bstatic
告訴連接器所有的庫(象libc等等)都使用靜態的版本。


★5.5.5 裝載附加的共享庫

在ELF系統上，為了執行一個ELF文件，內核要把控制權交給動態連接器
ld-linux.so.1(在linux上動態連接器是ld-linux.so.1，版本不同也會不同的，
在默認的redhat6.2上是/lib/ld-linux.so.2)。在絕對路徑/lib/ld-linux.so.1
以二進制存放著。假如動態連接器不存在，沒有哪個ELF可執行文件能運行。

動態連接器執行以下一個步驟完成從程序到進程映象：

1.分析可執行文件中的動態信息section，決定需要哪些庫。

2.定位和映象(map)那些共享庫，并且分析它們動態信息section
? 決定是否需要附加的共享庫。

3.為可執行程序和那些需要的共享庫執行重定位。

4.調用共享庫中提供的任何初始化函數并且安排共享庫提供的
? 清除(cleanup)函數在共享庫卸栽出進程空間的時候運行。

5.傳控制給程序

6.為應用程序提供函數的遲延裝定服務

7.為應用程序提供動態轉載服務。

環境變量LD_PRELOAD設置共享庫名或者用":"把文件名隔開。動態連接器在
任何那些請求的共享庫之前把環境變量LD_PRELOAD的共享庫裝載到進程地址
空間去。例如：

# LD_PRELOAD=./mylibc.so myprog

這里./mylibc.so將第一時間map到程序myprog的空間。因為動態連接器在找
尋標號的時候總是使用第一次碰到的標號，所以我們可以使用LD_PRELOAD來
覆蓋標準共享庫中的函數。這個特性對程序員來說是很有用的，可用來在還
沒有建好整個共享庫的時候對單個函數功能先做調試實驗。

我們可以這樣：
#gcc -c -fPIC -O3 print.c
#gcc -shared print.o -o print.so.1.0
創建自己的共享連接庫

★5.5.6 Linux下動態裝載(Dynamic loading)

_dlinfo是動態連接接口庫的一個函數。它列出所有映射到執行程序和通過
dlopen打開的每個共享庫。它的輸出類試以下：

List of loaded modules
00000000 50006163 50006200 Exe 1
50007000 5000620c 50006200 Lib 1 /lib/elf/libd1.so.1
5000a000 500062c8 50006200 Lib 2 /lib/elf/libc.so.4
50000000 50006000 00000000 Int 1 /lib/elf/ld-linux.so.1
500aa000 08006f00 08005ff0 Mod 1 ./libfoo.so

Modules for application (50006200):
50006163
5000620c /lib/elf/libdl.so.1
500062c8 /lib/elf/libc.so.4
50006000 /lib/ld-linux.so.1
Modules for handle 8005ff0
08006f00 ./libfoo.so
500062c8 /lib/elf/lib.so.4
50006163
5000620c /lib/elf/libd1.so.1
500062c8 /lib/elf/libc.so.4
50006000 /lib/elf/ld-linux.so.1

以上可被用來解釋動態的連接和動態的裝載。

在linux支持ELF上配置的GCC假如使用了-rdynamic選項，它將把
-export-dynamic傳給連接器。強烈建議使用動態裝載。這就是為什么在
我們的Makefile例子中使用了LDFLAGS=-rdynamic。暫時，這個選項只能在
linux下使用。但是-Wl,-export-dynamic能在其他的平臺上把-export-dynamic
傳給GNU的連接器。

你能在GNU link editor的[3]和[4]部分找到它詳細的描述。


★6 位置無關代碼(PIC)的匯編語言編程

當用gcc指定-fPIC的時候，gcc將從C源代碼中產生PIC的匯編語言代碼。但有
時候，我們需要用匯編語言來產生PIC代碼。

在ELF下，PIC的實現是使用基寄存器(base register)。在PIC下，所有的
標號引用都是通過基寄存器實現的，為此，要用匯編寫PIC的話，必須保存
基寄存器(base register)。由于位置無關代碼，控制傳送指令的目的地址
必須被替換或者是在PIC情況下計算的。對X86機器來說，該基寄存器
(base register)就是ebx.這里我們將介紹在X86上安全的PIC匯編代碼的
兩種方法。這些技術在Linux C庫中也被使用到。


★6.1 在C中內嵌匯編

gcc支持內嵌匯編的聲明，可讓程序員在C語言中使用匯編語言。當寫LINUX系
統調用接口的時候這是很有用的，而無須使用機器相關指令。

在linux 下系統調用是通過int $0x80的。一般的，系統調用會有三個參數:

#include <sys/syscall.h>

extern int errno;

int read( int fd,void *buf ,size count)
{
long ret;

__asm__ __volatile__ ("int $0x80"
:"=a"(ret)
:"O"(SYS_read),"b"((long)fd),
"c"((long)buf),"d"((long)count):"bx");

if (ret>=0)
{
return (int) ret:
}
errno=-ret;
retrun -1;
}

以上匯編代碼把系統調用號SYS_read放到了eax中，fd到ebx中，buf到
ecx中，count到edx中，從int $0x80中返回值ret放在eax中。在不用
-fPIC的情況下，這樣定義運行良好。帶-fPIC的gcc應該要檢查ebx是否被
被改變，并且應該在匯編代碼里保存和恢復ebx。但是不幸的是，事實上不是
這樣的。我們為了支持PIC必須自己寫匯編代碼。

#include <sys/syscall.h>

extern int errno;

int read( int fd,void *buf ,size count)
{
long ret;

__asm__ __volatile__ ("pushl %%ebx/n/t"
"movl %%esi,%%ebx/n/t"
"int $0x80/n/t"
"popl %%ebx"
:"=a"(ret)
:"O"(SYS_read),"S"((long)fd),
"c"((long)buf),"d"((long)count):"bx");

if (ret>=0)
{
return (int) ret:
}
errno=-ret;
return -1;
}

這里首先把fd放到esi中，然后保存ebx,把esi移到ebx，在int $0x80后恢復
ebx。這樣保證ebx不被改變(除了在int $0x80中斷調用中)。同樣的原則也
適用于其他內嵌的匯編。

在任何時候，當ebx可能要被改變時，千萬要記得保存和恢復ebx.


★6.2 用匯編語言編程

假如我們在系統調用時需要傳5個參數時候，內嵌的匯編代碼即使是PIC
的，也不能工作，因為x86沒有足夠的寄存器。我們需要直接用匯編語言
編寫。

syscall(int syscall_number,...)的一般匯編代碼如下：

.file "syscall.S"
.text
.global syscall
.global errno
.align 16

syscall:
pushl 5ebp
movl %esp,%ebp
pushl %edi
pushl %esi
pushl %ebx
movl 8(%ebp),%eax
movl 12(%ebp),%ebx
movl 16(%ebp),%ecx
movl 20(%ebp),%edx
movl 24(%ebp),%esi
movl 28(%ebp),%edi
int $0x80
test %eax,%eax
jpe .LLexit
negl %eax
movl %eax,errno
movl $-1, %eax

.LLexit:
popl %ebx
popl %esi
popl %edi
movl %ebp,%esp
popl %ebp
ret
.type syscall,@function
.L_syscall_end:
.size syscall,.L_syscall_end -syscall

在PIC下，我們必須通過GOT(global offset table)來訪問任何全局變量
(除了保存在基寄存器ebx中的)。修改的代碼如下：

.file "syscall.S"
.text
.global syscall
.global errno
.align 16
syscall:
pushl %ebp
movl %esp,%ebp
pushl %edi
pushl %esi
pushl %ebx
call .LL4
.LL4:
popl %ebx
addl $_GLOBAL_OFFSET_TABLE_+[.- .LL4],%ebx
pushl %ebx
movl 8(%ebp),%eax
movl 12(%ebp),%ebx
movl 16(%ebp),%ecx
movl 20(%ebp),%edx
movl 24(%ebp),%esi
movl 28(%ebp),%edi
int $0x80
popl %ebx
movl %eax,%edx
test %edx,%edx
jge .LLexit
negl %edx
movl errno@GOT(%ebx),%eax
movl %edx,(%eax)
movl $-1,%eax
.LLexit:
popl %ebx
popl %esi
popl %edi
movl %ebp,%esp
popl %ebp
ret
.type syscall,@function
.L_syscall_end:
.size syscall,.L_syscall_end-syscall

假如要得到PIC的匯編代碼，但是又不知道如何寫，你可以寫一個C的，然后如下
編譯：

#gcc -O -fPIC -S foo.c

它將告訴gcc產生匯編代碼foo.s輸出,根據需要，可以修改它。


★7 結束語

根據以上討論的，我們可以得出這樣的結論：ELF是非常靈活的二進制格式。
它提供了非常有用的功能。這種規范沒有給程序和程序員太多限制。它使
創建共享庫容易，使動態裝載和共享庫的結合更加容易。在ELF下，在C++
中，全局的構造函數和析構函數在共享庫和靜態庫中用同樣方法處理。


[譯注：
到此，文章是翻譯好了，但里面的一些東西看起來可能
有點問題，比如說_libc_subinit section沒有他說的
那個功能，-dynamic-linker選項在默認的redhat 6.2系統
上不能用，_dlinfo動態連接接口庫函數好象在linux沒有實現
等等一系列問題，歡迎討論指正
mailto: alert7@21cn.com
??????????????? alert7@xfocus.org
]

參考：

1. Operating System API Reference:UNIX SVR4.2,UNIX Press,1992

2. SunOs 5.3 Linker and Libraries Manual,SunSoft ,1993.

3. Richard M.Stallman,Using and porting GNU CC for version 2.6,
?? Free Software Foundation,September 1994.

4. Steve Chamberlain and Roland Pesch,Using ld:The GNU linker,ld
?? version 2,Cygnus Support,January 1994.

總結

以上是生活随笔為你收集整理的从程序员角度看ELF的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。