對gcc編譯生成的客戶(hù)端主執行文件depagtd和cygwin編譯生成的相同文件進(jìn)行簡(jiǎn)單的分析,論
證兩者可以互換使用。
使用工具:gcc, readelf,objdump, BC。
Ia32版本:
Elf頭分析:

主要不同有兩點(diǎn):
1、program headers,gcc生成的有7個(gè),cygwin生成的有6個(gè)。具體如下:

gcc比cygwin多了一個(gè)STACK Segment,在ELF的標準中查詢(xún)沒(méi)有這個(gè)program header, (http://www.caldera.com/developers/gabi/2003-12-17/ch5.pheader.html)猜測是redhat公司自己的擴展。它的offset,virtaddr,phyaddr,filesize等參數全部為0,而且在Section to Segment mapping中STACK沒(méi)有映射任何section,所以不管在程序link和load時(shí)候這個(gè)Segment應該都不起作用。
2、 section headers,gcc生成的有27個(gè),cygwin生成的有31個(gè)。具體如下:

cygwin比gcc多了四個(gè)section:debug_arranges;debug_info;debug_abbrev;debug_line,從名字來(lái)看,全部都是關(guān)于調試信息的section,在編譯時(shí)并沒(méi)有加-g參數,所以應該是在編譯交叉編譯器時(shí)候的缺省設定導致。反編譯之后這幾個(gè)section信息都是關(guān)于crosstool的版本信息。
可以看出,都是關(guān)于使用的交叉編譯器的gcc,glibc的版本信息及編譯交叉編譯器工具crosstool信息,對程序的exec和load沒(méi)有影響。
(背景知識參照:http://www.caldera.com/developers/gabi/2003-12-17/contents.html ;
http://blog.chinaunix.net/u3/94916/showart_1908331.html)
Te
Text段分析:
1、匯編后結果基本相同的例子:

2、匯編后結果有差異的例子:

以下面C語(yǔ)句為例分析差異:
openlog("depagtd", LOG_PID, LOG_DAEMON);
Linux從右向左參數壓棧。
gccdump cygwindump
push $0x18 movl $0x18,0x8(%esp)
push $0x1 movl $0x1,0x4(%esp)
push $0x8056dc0 movl $0x80576e0 (%esp)
call 8049444
從syslog.h查到:
#define LOG_PID 0x01 /* log the pid with each message */
#define LOG_DAEMON (3<<3)
從elf只讀數據段查到:
Contents of section .rodata: Contents of section .rodata:
8056db8 03000000 01000200 64657061 67746400 ........depagtd. 80576c0 03000000 01000200 00000000 00000000 ................
80576d0 00000000 00000000 00000000 00000000 ................
80576e0 64657061 67746400 5b455252 4f525d73 depagtd.[ERROR]s
差別主要在參數壓棧的表示形式上不同,編譯機上的gcc直接編譯的程序,參數壓棧時(shí)使用push指令,而cygwin中的交叉編譯環(huán)境的gcc編譯的程序,參數壓棧時(shí)使用movl指令。(因為esp是棧指針)
關(guān)鍵地方的跳轉指令和判斷指令相同。
結論:可以使用交叉編譯器生成的可執行文件代替原有編譯器生成的可執行文件。
聯(lián)系客服