IOS可执行文件学习总结
生活随笔
收集整理的這篇文章主要介紹了
IOS可执行文件学习总结
小編覺得挺不錯的,現在分享給大家,幫大家做個參考.
了解iOS上的可執行文件和Mach-O格式
http://www.cocoachina.com/mac/20150122/10988.html?
很多朋友都知道，在Windows上exe是可直接執行的文件擴展名，而在Linux（以及很多版本的Unix）系統上ELF是可直接執行的文件格式，那么在蘋果的操作系統上又是怎樣的呢？在iOS（和Mac OS X）上，主要的可執行文件格式是Mach-O格式。本文就關于iOS上的可執行文件和Mach-O格式做一個簡要整理。
Mach-O格式是iOS系統上應用程序運行的基礎，了解Mach-O的格式，對于調試、自動化測試、安全都有意義。在了解二進制文件的數據結構以后，一切就都顯得沒有秘密。
0. Mach與Mach-O
這里先提醒大家一下，Mach不是Mac，Mac是蘋果電腦Macintosh的簡稱，而Mach則是一種操作系統內核。Mach內核被NeXT公司的NeXTSTEP操作系統使用。在Mach上，一種可執行的文件格是就是Mach-O（Mach Object file format）。1996年，喬布斯將NeXTSTEP帶回蘋果，成為了OS X的內核基礎。所以雖然Mac OS X是Unix的“后代”，但所主要支持的可執行文件格式是Mach-O。
iOS是從OS X演變而來，所以同樣是支持Mach-O格式的可執行文件。
1. iOS可執行文件初探
作為iOS客戶端開發者，我們比較熟悉的一種文件是ipa包（iPhone Application）。但實際上這只是一個變相的zip壓縮包，我們可以把一個ipa文件直接通過unzip命令解壓。
解壓之后，會有一個Payload目錄，而Payload里則是一個.app文件，而這個實際上又是一個目錄，或者說是一個完整的App Bundle。
在這個目錄中，里面體積最大的文件通常就是和ipa包同名的一個二進制文件。找到它，我們用file命令來看一下這個文件的類型：
XXX: Mach-O universal binary with 2 architectures
XXX (for architecture armv7): Mach-O executable arm
XXX (for architecture armv7s): Mach-O executable arm
由此看來，這是一個支持armv7和armv7s兩種處理器架構的通用程序包，里面包含的兩部分都是Mach-O格式。
對于一個二進制文件來講，每個類型都可以在文件最初幾個字節來標識出來，即“魔數”。比如PNG圖片的最初幾個字節是\211 P N G \r \n \032 \n （89 50 4E 47 0D 0A 1A 0A）。我們再來看下這個Mach-O universal binary的:
0000000 ca fe ba be 00 00 00 02 00 00 00 0c 00 00 00 09
沒錯，開始的4個字節是cafe babe，即“Cafe baby”。了解Java或者說class文件格式的同學可能會很熟悉，這也是.class文件開頭的“魔數”，但貌似是Mach-O在更早的時候就是用了它。在OS X上，可執行文件的標識有這樣幾個魔數（也就是文件格式）：
cafebabe
feedface
feadfacf
還有一個格式，就是以#!開頭的腳本
cafebabe就是跨處理器架構的通用格式，feedface和feedfacf則分別是某一處理器架構下的Mach-O格式，腳本的就很常見了，比如#!/bin/bash開頭的shell腳本。
這里注意一點是，feedface和cafebabe的字節順序不同，我們可以用lipo把上面cafebabe的文件拆出armv7架構的，看一下開頭的幾個字節：
0000000 ce fa ed fe 0c 00 00 00 09 00 00 00 02 00 00 00
2. Mach-O格式
接下來我們再來看看這個Mach-O格式到底是什么樣的格式。我們可以通過二進制查看工具查看這個文件的數據，結果發現，不是所有數據都是相連的，而是被分成了幾個段落。
在一位叫做JOE SAVAGE的老兄發布的圖片上來看，Mach-O的文件數據顯現出來是這個樣子的：
Hello-World-Hilbert-Visualisation-Structure.png
(圖形化的Mach-O文件數據)
大家可以對數據的分布感受下。
雖然被五顏六色的標記出來，可能這還不是特別直接。再來引用蘋果官方文檔的示意圖：
mach_o_segments.gif
(Mach-O文件格式基本結構)
從這張圖上來看，Mach-O文件的數據主體可分為三大部分，分別是頭部（Header）、加載命令（Load commands）、和最終的數據（Data）。
回過頭來，我們再看上面那張圖，也許就都明白了。黃色部分是頭部、紅色是加載命令、而其它部分則是被分割成Segments的數據。
3. Mach-O頭部
這里，我們用otool來看下Mach-O的頭部信息，得到：
? ? ? magic cputype cpusubtype ?caps ? ?filetype ncmds sizeofcmds ? ? ?flags
?0xfeedface ? ? ?12 ? ? ? ? ?9 ?0x00 ? ? ? ? ?2 ? ?45 ? ? ? 4788 0x00218085
更詳細的，我們可以通過otool的V參數得到翻譯版：
Mach header
? ? ? magic cputype cpusubtype ?caps ? ?filetype ncmds sizeofcmds ? ? ?flags
? ?MH_MAGIC ? ? ARM ? ? ? ? V7 ?0x00 ? ? EXECUTE ? ?45 ? ? ? 4788 ? NOUNDEFS DYLDLINK TWOLEVEL WEAK_DEFINES BINDS_TO_WEAK PIE
前面幾個字段的意義，上下對比就能看懂，我這里主要說下這樣幾個字段：
filetype，這個可以有很多類型，靜態庫（.a）、單個目標文件（.o）都可以通過這個類型標識來區分。
ncmds和sizeofcmds，這個cmd就是加載命令，ncmds就是加載命令的個數，而sizeofcmds就是所占的大小。
flags里包含的標記很多，比如TWOLEVEL是指符號都是兩級格式的，符號自身+加上自己所在的單元，PIE標識是位置無關的。
4. 加載命令
上面頭部中的數據已經說明了整個Mach-O文件的基本信息，但整個Mach-O中最重要的還要數加載命令。它說明了操作系統應當如何加載文件中的數據，對系統內核加載器和動態鏈接器起指導作用。一來它描述了文件中數據的具體組織結構，二來它也說明了進程啟動后，對應的內存空間結構是如何組織的。
我們可以用otool -l xxx來看一個Mach-O文件的加載命令：
Load command 0
? ? ? cmd LC_SEGMENT
? cmdsize 56
? segname __PAGEZERO
? ?vmaddr 0x00000000
? ?vmsize 0x00004000
? fileoff 0
?filesize 0
? maxprot ---
?initprot ---
? ?nsects 0
? ? flags (none)
Load command 1
? ? ? cmd LC_SEGMENT
? cmdsize 736
? segname __TEXT
? ?vmaddr 0x00004000
? ?vmsize 0x00390000
? fileoff 0
?filesize 3735552
? maxprot r-x
?initprot r-x
? ?nsects 10
? ? flags (none)
Section
? sectname __text
? ?segname __TEXT
? ? ? addr 0x0000b0d0
? ? ? size 0x0030e7f4
上面這段是執行結果的一部分，是加載PAGE_ZERO和TEXT兩個segment的load command。PAGE_ZERO是一段“空白”數據區，這段數據沒有任何讀寫運行權限，方便捕捉總線錯誤（SIGBUS）。TEXT則是主體代碼段，我們注意到其中的r-x，不包含w寫權限，這是為了避免代碼邏輯被肆意篡改。
我再提一個加載命令，LC_MAIN。這個加載指令，會聲明整個程序的入口地址，保證進程啟動后能夠正常的開始整個應用程序的運行。
除此之外，Mach-O里還有LC_SYMTAB、LC_LOAD_DYLIB、LC_CODE_SIGNATURE等加載命令，大家可以去官方文檔查找其含義。
至于Data部分，在了解了頭部和加載命令后，就沒什么特別可說的了。Data是最原始的編譯數據，里面包含了Objective-C的類信息、常量等。
本文是對Mach-O文件格式的一個理解小結，希望能夠拋磚引玉，幫助各位朋友把握可執行文件的主題脈絡，進而解決各類問題。
參考：
THE NITTY GRITTY OF “HELLO WORLD” ON OS X
OS X ABI Mach-O File Format Reference
========
iOS APP可執行文件的組成
http://blog.cnbang.net/tech/2296/iOS APP編譯后，除了一些資源文件，剩下的就是一個可執行文件，有時候項目大了，引入的庫多了，可執行文件很大，想知道這個可執行文件的構成是怎樣，里面的內容都是些什么，哪些庫占用空間較高，可以用以下方法勘察：
1.XCode開啟編譯選項Write Link Map File
XCode -> Project -> Build Settings -> 搜map -> 把Write Link Map File選項設為yes，并指定好linkMap的存儲位置
linkmap
2.編譯后，到編譯目錄里找到該txt文件，文件名和路徑就是上述的Path to Link Map File
位于~/Library/Developer/Xcode/DerivedData/XXX-eumsvrzbvgfofvbfsoqokmjprvuh/Build/Intermediates/XXX.build/Debug-iphoneos/XXX.build/
這個LinkMap里展示了整個可執行文件的全貌，列出了編譯后的每一個.o目標文件的信息（包括靜態鏈接庫.a里的），以及每一個目標文件的代碼段，數據段存儲詳情。
1
以伊書項目為例，在LinkMap里首先列出來的是目標文件列表：
# Object files:
[ 0] linker synthesized
[ 1] /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator7.0.sdk/usr/lib/crt1.o
[ 2] /Users/bang/Library/Developer/Xcode/DerivedData/yishu-eyzgphknrrzpevagadjtwpzzeqag/Build/Intermediates/yishu.build/Debug-iphonesimulator/yishu.build/Objects-normal/i386/TKPFileInfo.o
...
[280] /Users/bang/Downloads/yishu/yishu/Classes/lib/UMeng/MobClick/libMobClickLibrary.a(UMANJob.o)
[281] /Users/bang/Downloads/yishu/yishu/Classes/lib/UMeng/MobClick/libMobClickLibrary.a(UMANWorker.o)
[282] /Users/bang/Downloads/yishu/yishu/Classes/lib/UMeng/MobClick/libMobClickLibrary.a(MobClick.o)
[283] /Users/bang/Downloads/yishu/yishu/Classes/lib/UMeng/MobClick/libMobClickLibrary.a(UMANLaunch.o)
...
前面中括號里的是這個文件的編號，后面會用到，像項目里引用到靜態鏈接庫libMobClickLibrary.a里的目標文件都會在這里列出來。
2
接著是一個段表，描述各個段在最后編譯成的可執行文件中的偏移位置及大小，包括了代碼段（__TEXT，保存程序代碼段編譯后的機器碼）和數據段（__DATA，保存變量值）
# Sections:
# Address ? Size ? ? Segment ? Section
0x00002740 0x00273890 __TEXT __text
0x00275FD0 0x00000ADA __TEXT __symbol_stub
0x00276AAC 0x00001222 __TEXT __stub_helper
0x00277CCE 0x00019D9E __TEXT __objc_methname
0x00291A70 0x00012847 __TEXT __cstring
0x002A42B7 0x00001FC1 __TEXT __objc_classname
0x002A6278 0x000046A7 __TEXT __objc_methtype
0x002AA920 0x000061CE __TEXT __ustring
0x002B0AF0 0x00000764 __TEXT __const
0x002B1254 0x000028B8 __TEXT __gcc_except_tab
0x002B3B0C 0x00004EBC __TEXT __unwind_info
0x002B89C8 0x0003662C __TEXT __eh_frame
0x002EF000 0x00000014 __DATA __program_vars
0x002EF014 0x00000284 __DATA __nl_symbol_ptr
0x002EF298 0x0000073C __DATA __la_symbol_ptr
0x002EF9E0 0x000030A4 __DATA __const
0x002F2A84 0x00000590 __DATA __objc_classlist
0x002F3014 0x0000000C __DATA __objc_nlclslist
0x002F3020 0x0000006C __DATA __objc_catlist
0x002F308C 0x000000D8 __DATA __objc_protolist
0x002F3164 0x00000008 __DATA __objc_imageinfo
0x002F3170 0x0002BC80 __DATA __objc_const
0x0031EDF0 0x00003A30 __DATA __objc_selrefs
0x00322820 0x00000014 __DATA __objc_protorefs
0x00322834 0x000006B8 __DATA __objc_classrefs
0x00322EEC 0x00000394 __DATA __objc_superrefs
0x00323280 0x000037C8 __DATA __objc_data
0x00326A48 0x000096D0 __DATA __cfstring
0x00330118 0x00001424 __DATA __objc_ivar
0x00331540 0x00006080 __DATA __data
0x003375C0 0x0000001C __DATA __common
0x003375E0 0x000018E8 __DATA __bss
首列是數據在文件的偏移位置，第二列是這一段占用大小，第三列是段類型，代碼段和數據段，第四列是段名稱。
每一行的數據都緊跟在上一行后面，如第二行__symbol_stub的地址0x00275FD0就是第一行__text的地址0x00002740加上大小0x00273890，整個可執行文件大致數據分布就是這樣。
這里可以清楚看到各種類型的數據在最終可執行文件里占的比例，例如__text表示編譯后的程序執行語句，__data表示已初始化的全局變量和局部靜態變量，__bss表示未初始化的全局變量和局部靜態變量，__cstring表示代碼里的字符串常量，等等。
3
接著就是按上表順序，列出具體的按每個文件列出每個對應字段的位置和占用空間
# Address Size File Name
0x00002740 0x0000003E [ 1] start
0x00002780 0x00000400 [ 2] +[TKPFileInfo parseWithDictionary:]
0x00002B80 0x00000030 [ 2] -[TKPFileInfo fileID]
...
同樣首列是數據在文件的偏移地址，第二列是占用大小，第三列是所屬文件序號，對應上述Object files列表，最后是名字。
例如第二行代表了文件序號為2（反查上面就是TKPFileInfo.o）的parseWithDictionary方法占用了1000byte大小。
使用
這個文件可以讓你了解整個APP編譯后的情況，也許從中可以發現一些異常，還可以用這個文件計算靜態鏈接庫在項目里占的大小，有時候我們在項目里鏈了很多第三方庫，導致APP體積變大很多，我們想確切知道每個庫占用了多大空間，可以給我們優化提供方向。LinkMap里有了每個目標文件每個方法每個數據的占用大小數據，所以只要寫個腳本，就可以統計出每個.o最后的大小，屬于一個.a靜態鏈接庫的.o加起來，就是這個庫在APP里占用的空間大小。
========
iOS 系列譯文：Mach-O 可執行文件
http://www.cocoachina.com/industry/20131121/7392.html當我們在Xcode中構建一個程序的時候，其中有一部分就是把源文件（.m和.h）文件轉變成可執行文件。這個可執行文件包含了將會在CPU（iOS設備上的arm處理器或者你mac上的Intel處理器）運行的字節
“”
閱讀器
iOS
當我們在Xcode中構建一個程序的時候，其中有一部分就是把源文件（.m和.h）文件轉變成可執行文件。這個可執行文件包含了將會在CPU（iOS設備上的arm處理器或者你mac上的Intel處理器）運行的字節碼。
?
我們將會過一遍編譯器這個過程的做了些什么，同時也看一下可執行文件的內部到底是怎樣的。其實，里面的東西比你看到的要多很多。
?
讓我們先把Xcode放一邊，踏入Commond-Lines的大陸。當我們在Xcode中構建一個App時，Xcode只是簡單的調用了一系列的工具而已。希望這將會讓你更好的明白一個可執行文件（被稱之為Mach-O可執行文件），是怎樣組裝起來的，并且是怎樣在iOS或者os x上執行的
XCrun
?
先從一些基礎性的東西開始：我們將會使用一個叫做Xcrun的命令行工具。他看起來很奇怪，但是的確相當出色。這個小工具是用來調用其他工具的。 原先的時候我們執行：
% clang -v?
?現在在終端中，我們可以執行：
% xcrun clang -v?
?Xcrun定位Clang，并且使用相關的參數來執行Clang。
?
為什么我們要做這個事情？這看起來毫無重點，胡扯八道。但是Xcrun允許我們使用多個版本的Xcode，或者使用特定Xcode版本里面的工具，或者針對特點的SDK使用不同的工具。如果你恰好有Xcode4.5和xcode5、使用xcode-select和xcrun你可以選擇選擇使用來自Xcode4.5里面的SDK的工具，或者來自Xcode5里面的SDK的工具。在大多數其他平臺上，這將是一個不可能的事情。如果你看一下幫助手冊上xcode-select和xcrun的一些細節。你就能在不安裝命令行工具的情況下，使用在終端中使用開發者工具。
?
一個不使用IDE的Hello World
?
回到終端，創建一個包含一個c文件的目錄：
% mkdir ~/Desktop/objcio-command-line?
% cd !$?
% touch helloworld.c?
現在使用你喜歡的文本編輯器來編輯這個文件，例如TextEdit.app：
% open -e helloworld.c?
錄入下面的代碼：
#include <stdio.h>?
int main(int argc, char *argv[])?
{?
? ? printf("Hello World!\n");?
? ? return 0;?
}?
保存，并且回到終端執行：
% xcrun clang helloworld.c?
% ./a.out?
現在你能夠在終端上看到熟悉的Hello World！。你編譯了一個C程序并且執行了它。所有都是在不使用IDE的情況下做的。深呼吸一下，高興高興。我們在這里做了些什么？我們將hellowrold.c編譯成了叫a.out的Mach-o二進制文件。a.out是編譯器的默認名字，除非你指定一個別的。
?
Hello World和編譯器
?
現在可選擇的編譯器是Clang（讀作：/’kl /）。Chris寫了一些更多關于Clang細節的介紹，可以參考： about the compiler
?
概括一下就是，編譯器將會讀入處理hellowrold.c，輸出可執行文件a.out。這個過程包含了非常多的步驟。我們所要做的就是正確的執行它們。
?
預處理:
序列化
宏定義展開
#include展開（引用文件展開）
語法和語義分析：
使用預處理后的單詞構建詞法樹
執行語義分析生成語法樹
輸出AST （Abstract Syntax Tree）
?
代碼生成和優化
將AST轉化成更低級的中間碼（LLVM IR）
優化生成代碼
目標代碼生成
輸出匯編代碼
?
匯編程序
將匯編代碼轉化成目標文件
連接器
?
將多個目標文件合并成可執行文件（或者一個動態庫） 我們來看一個關于這些步驟的簡單的例子。
?
預處理
編譯器將做的第一件事情是處理文件。使用Clang展示一下這個過程：
% xcrun clang -E helloworld.c?
歐耶。輸出了413行內容。打開個編輯器看看到底發生了什么：
% xcrun clang -E helloworld.c | open -f?
在文件頂部我們能看到很多以”#”開頭的行。這些被稱之為行標記語句的語句告訴我們它后面的內容來自哪里。我們需要這個。如果我再看一下hellowrold.c，第一行是：
#include <stdio.h>?
我們都用過#include和#import。它們做的就是告訴于處理器在#include語句的地方插入stdio.h的內容。在剛剛的文件里就是插入了一個以#開頭的行標記。跟在#后面的數字是在源文件中的行號。每一行最后的數字是在新文件中的行號。回到剛才打開的文件，接下來是系統頭文件，或者一些被看成包裹著extern “C”的文件。
?
如果你滾動到文件末尾，你將會發現我們的helloworld.c的代碼：
# 2 "helloworld.c" 2?
int main(int argc, char *argv[])?
{?
? ? ?printf("Hello World!\n");?
? ? ?return 0;?
}?
在Xcode中，你可以通過使用Product->Perform Action-> Preprocess來查看任何一個文件的預處理輸出。一定要注意這將會花費一些時間來加載預處理輸出文件（接近100，000行）。
?
編譯
?
下一個步驟：文本處理和代碼生成。我們可以調用clang輸出匯編代碼就像這樣：
% xcrun clang -S -o - helloworld.c | open -f?
看一看輸出。我們首先注意到的是一些以點開頭的行。這些是匯編指令。其他的是真正的x86_64匯編代碼。最后是些標記，就像C中的那些標記一樣。
?
我們從前三行開始：
.section ? ?__TEXT,__text,regular,pure_instructions?
.globl ?_main?
.align ?4, 0x90?
這三行是匯編指令，不是匯編代碼。”.section”指令指出了哪一個段接下來將會被執行。比用二進制表示好看多了。
?
下一個，.global指令說明_main是一個外部符號。這就是我們的main（）函數。它能夠從我們的二進制文件之外看到，因為系統要調用它來運行可執行文件。
?
.align指令指出了下面代碼的對齊方式。從我們的角度看，接下來的代碼將會按照16比特對齊并且如果需要的時候用0×90補齊。
?
下面是main函數的頭部：
_main: ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?## @main?
? ? .cfi_startproc?
## BB#0:?
? ? pushq ? %rbp?
Ltmp2:?
? ? .cfi_def_cfa_offset 16?
Ltmp3:?
? ? .cfi_offset %rbp, -16?
? ? movq ? ?%rsp, %rbp?
Ltmp4:?
? ? .cfi_def_cfa_register %rbp?
? ? subq ? ?$32, %rsp?
這一部分有一些和C標記工作機制一樣的一些標記。它們是某些特定部分的匯編代碼的符號鏈接。首先是_main函數真正的開始地址。這個也是被拋出的符號。二進制文件將會在這個地方產生一個引用。
?
.cfi_startproc指令一半會在函數開始的地方使用。CFI是Call Frame Information的縮寫。幀松散的與一個函數交互。當你使用調試器，并且單步執行的時候，你實際上是在調用幀中跳轉。在C代碼中，函數有自己的調用幀，除了函數之外的一些結構也會有調用站。.cfi_startproc指令給了函數一個.en_frame的入口，這個入口包含了堆棧展開信息（表示異常如何展開調用幀堆棧）。這個指令也會發送一些和具體平臺相關的指令給CFI。文件后面的.cfi_endproc與.cfi_startproc相匹配，來表示結束main函數。
?
下一步，這里有另外一個Label ## BB#0.然后，終于來了第一句匯編代碼：pushq %rbp。從這里開始事情開始變得有趣。在OS X上，我們將會有x84_64的代碼。對于這種架構，有一個東西叫做ABI（application binary interface），ABI表示函數調用是怎樣在匯編代碼層面上工作的。ABI指出在函數調用時，rbp寄存器必須被保護起來。這是main函數的責任，來確保返回時，rbp寄存器中有數據。pushq %rbp將它的數據推進堆棧，以便我們以后使用。
?
下面是，兩個CFI指令： .cfi_def_cfa_offset 16 和 .cfi_offset %rbp, -16. 這將會輸出一些信息，這些信息是關于生成調用堆棧展開信息和調試信息的。我們改變了堆棧，并且這兩個指令告訴編譯器指針指向哪里，或者它們說出了之后調試器將會使用的信息。
?
現在movq %rsp， %rbp將會把局部變量加載進堆棧。subq $32，%rsp將堆棧指針移動32比特，也就是函數將會調用的位置。我們先在rbp中存儲了老的堆棧指針，然后將此作為我們局部變量的基址，然后我們更新堆棧指針到我們將會使用的位置。
?
之后，我們調用了printf（）：
leaq ? ?L_.str(%rip), %rax?
movl ? ?$0, -4(%rbp)?
movl ? ?%edi, -8(%rbp)?
movq ? ?%rsi, -16(%rbp)?
movq ? ?%rax, %rdi?
movb ? ?$0, %al?
callq ? _printf?
首先，leaq加載到L_.str的指針到寄存器rax。注意L_.str標記是怎樣在下面的代碼中定義的。它就是C字符串“hello world！\n”。寄存器edi和rsi保存了函數的第一個和第二個參數。直到我們調用其他函數，我們第一步需要存儲它們當前值。這就是為什么我們使用剛剛存儲的rbp偏移32比特的原因。第一個32比特是零，之后32個比特是edi的值（存儲了argc），然后是64bit的rsi寄存器的值。我們在后面不會使用這些數據。但是如果編譯器沒有使用優化的時候，它們還是會被存下來。
?
現在，我們將會把第一個函數（printf）的參數加載進寄存器edi。printf函數是一個可變參數的函數。ABI調用約定指定，將會把使用來存儲參數的寄存器數量存儲在寄存器al中。對我們來講是0。最后callq調用了printf函數。
movl ? ?$0, %ecx?
movl ? ?%eax, -20(%rbp) ? ? ? ? ## 4-byte Spill?
movl ? ?%ecx, %eax?
這將設置ecx寄存的值為0，并且把eax的值壓棧。然后從ecx復制0到eax。ABI指定eax將會存儲函數的返回值，我們man函數的返回值是0：
addq ? ?$32, %rsp?
popq ? ?%rbp?
ret?
.cfi_endproc?
函數執行完成后，將恢復堆棧指針，通過上移32bit在rsp中的堆棧指針。我們將會出棧我們早先存儲的rbp的值，然后調用ret來返回，ret將會讀取離開堆棧的地址。.cfi_endproc平衡了.cfi_startproc指令。
?
下一步是一個字一個字的輸出我們的字符串：“hello world!\n”:
?
之后.section指令指出下面將要跳入的段。L_.str標記允許獲取一個字符轉的指針。.asciz指定告訴匯編器輸出一個0的字符串結尾。
?
__TEXT __cstring開始了一個新的段。這個段包含了C字符串：
.section ? ?__TEXT,__cstring,cstring_literals?
tr: ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ## @.str?
.asciz ? "Hello World!\n"?
這兩行創建了一個沒有結束符的字符創。注意L_.str是怎樣命名，和來獲取字符串的。
?
最后.subseciton_via_symbols指令是靜態鏈接編輯器使用的。
?
更多關于匯編指令的信息可以從蘋果的Apple’s assemebler reference獲取。AMD64網站有關于ABI for x86的文檔。同時也有Gentle Introduction to x86-64 Assemble。 再一次，Xcode允許你查看任何文件的匯編代碼通過 Product->Perform Action -> Assemble.
?
匯編編譯器：
匯編編譯器，只是簡單的將匯編代碼轉換成機器碼。它創建了一個目標文件。這些文件以.o結尾。如果你使用Xcode構建一個app，你將會在Derived Data目錄下面的你的工程目錄中的objects-normal目錄下面發現這些文件。
?
連接器：
我們將會多談一點關于鏈接的東西。但是簡單的說，連接器確定了目標文件和庫之間的鏈接。這是什么意思？ 重新調用 callq _printf. printf是在libc庫中的一個函數。無論怎樣，最后的可執行文件需要能知道printf（）在內存中的什么位置。例如符號_printf的地址。連接器將會讀取所有的目標文件，所有的庫和結束任何未定義的符號。然后將它們編碼進最后的可執行文件，然后輸出最后的可執行文件：a.out。
?
段
就像我們上面提到的一樣，這里有些東西叫做段。一個可執行文件包含多個段。可執行文件不同的部分將會加載進不同的段。并且每個段將會轉化進一個“Segment”中。這對我們隨便寫的app如此，對我們用心寫的app也一樣。
?
我們來看看在a.out中的段。我們可以使用size：
% xcrun size -x -l -m a.out ?
Segment __PAGEZERO: 0x100000000 (vmaddr 0x0 fileoff 0)?
Segment __TEXT: 0x1000 (vmaddr 0x100000000 fileoff 0)?
? ? Section __text: 0x37 (addr 0x100000f30 offset 3888)?
? ? Section __stubs: 0x6 (addr 0x100000f68 offset 3944)?
? ? Section __stub_helper: 0x1a (addr 0x100000f70 offset 3952)?
? ? Section __cstring: 0xe (addr 0x100000f8a offset 3978)?
? ? Section __unwind_info: 0x48 (addr 0x100000f98 offset 3992)?
? ? Section __eh_frame: 0x18 (addr 0x100000fe0 offset 4064)?
? ? total 0xc5?
Segment __DATA: 0x1000 (vmaddr 0x100001000 fileoff 4096)?
? ? Section __nl_symbol_ptr: 0x10 (addr 0x100001000 offset 4096)?
? ? Section __la_symbol_ptr: 0x8 (addr 0x100001010 offset 4112)?
? ? total 0x18?
Segment __LINKEDIT: 0x1000 (vmaddr 0x100002000 fileoff 8192)?
total 0x100003000?
a.out文件有四個段。其中一些有section。
?
當我們執行一個可執行文件。虛擬內存系統會將segment映射到進程的地址空間中。映射完全不同于我們一般的認識，但是如果你對虛擬內存系統不熟悉，可以簡單的想象VM會將整個文件加載進內存，雖然在實際上這不會發生。VM使用了一些技巧來避免全部加載。
?
當虛擬內存系統進行映射時，數據段和可執行段會以不同的參數和權限被映射。
?
__TEXT段包含了可執行的代碼。它們被以只讀和可執行的方式映射。進程被允許執行這些代碼，但是不能修改。這些代碼也不能改變它們自己，并且這些頁從來不會被污染。
?
__DATA段以可讀寫和不可執行的方式映射。它包含了將會被更改的數據。
?
第一個段是__PAGEZERO。這個有4GB大小。這4GB并不是文件的真實大小，但是說明了進程的前4GB地址空間將會被映射為，不能執行，不能讀，不能寫。這就是為什么在去寫NULL指針或者一些低位的指針的時候，你會得到一個EXC_BAD_ACCESS錯誤。這是操作系統在嘗試防止你引起系統崩潰。
?
在每一個段內有一些片段。它們包含了可執行文件的不同的部分。在_TEXT段，_text片段包含了編譯得到的機器碼。_stubs和_stub_helper是給動態鏈接器用的。著允許動態鏈接的代碼延遲鏈接。_const是不可變的部分，就像_cstring包含了可執行文件的字符串一樣。
?
_DATA段包含了可讀寫數據。從我們的角度，我們只有_nl_sysmol_ptr 和__la_symble_ptr，它們是延遲鏈接的指針。延遲鏈接的指針被用來執行未定義的函數。例如，那些沒有包含在可執行文件本身內部的函數。它們將會延遲加載。那些非延遲鏈接的指針將會在可執行文件被夾在的時候確定。
?
其他在_DATA中共同的段是_const。她包含了那些需要重定位的不可變數據。一個例子是chat* const p = “foo”; p指針指向的數據不是靜態的。_bss片段包含了沒有被初始化的靜態變量例如static int a； ANSI C標準指出這些靜態變量將會被設置為零。但是在運行時可以被改變。_common片段包含了被動態鏈接器使用的占位符片段。
?
蘋果的文檔OSX Assembler Reference有更多關于片段定義的內容。
?
段內容：
我們能檢查每一個片段的內容，使用otool像這樣：
% xcrun otool -s __TEXT __text a.out ?
a.out:?
(__TEXT,__text) section?
0000000100000f30 55 48 89 e5 48 83 ec 20 48 8d 05 4b 00 00 00 c7 ?
0000000100000f40 45 fc 00 00 00 00 89 7d f8 48 89 75 f0 48 89 c7 ?
0000000100000f50 b0 00 e8 11 00 00 00 b9 00 00 00 00 89 45 ec 89 ?
0000000100000f60 c8 48 83 c4 20 5d c3?
這就是我們app的代碼。從-s __TEXT __text非常普通，otool有一個對此的縮寫，使用-t.我們甚至可以看反匯編的代碼通過在后面加上-v:
% xcrun otool -v -t a.out?
a.out:?
(__TEXT,__text) section?
_main:?
0000000100000f30 ? ?pushq ? %rbp?
0000000100000f31 ? ?movq ? ?%rsp, %rbp?
0000000100000f34 ? ?subq ? ?$0x20, %rsp?
0000000100000f38 ? ?leaq ? ?0x4b(%rip), %rax?
0000000100000f3f ? ?movl ? ?$0x0, 0xfffffffffffffffc(%rbp)?
0000000100000f46 ? ?movl ? ?%edi, 0xfffffffffffffff8(%rbp)?
0000000100000f49 ? ?movq ? ?%rsi, 0xfffffffffffffff0(%rbp)?
0000000100000f4d ? ?movq ? ?%rax, %rdi?
0000000100000f50 ? ?movb ? ?$0x0, %al?
0000000100000f52 ? ?callq ? 0x100000f68?
0000000100000f57 ? ?movl ? ?$0x0, %ecx?
0000000100000f5c ? ?movl ? ?%eax, 0xffffffffffffffec(%rbp)?
0000000100000f5f ? ?movl ? ?%ecx, %eax?
0000000100000f61 ? ?addq ? ?$0x20, %rsp?
0000000100000f65 ? ?popq ? ?%rbp?
0000000100000f66 ? ?ret?
這里有些內容反匯編的代碼中的一樣，你應該感覺很熟悉，這就是我們在前面編譯時候的代碼。唯一的不同就是，在這里我們沒有任何的匯編指令在里面。這是純粹的二進制執行文件。
?
同樣的方法，我們可以查案一下其他片段：
% xcrun otool -v -s __TEXT __cstring a.out?
a.out:?
Contents of (__TEXT,__cstring) section?
0x0000000100000f8a ?Hello World!\n?
?或者：
% xcrun otool -v -s __TEXT __eh_frame a.out ?
a.out: ? ??
Contents of (__TEXT,__eh_frame) section?
0000000100000fe0 ? ?14 00 00 00 00 00 00 00 01 7a 52 00 01 78 10 01 ?
0000000100000ff0 ? ?10 0c 07 08 90 01 00 00?
關于性能的腳注
從側面來講，_DATA和_TEXT段會影響性能。如果你有一個非常大的二進制文件，你可能回想查看蘋果的代碼大小優化指南。將數據移到__TEXT段是個不錯的選擇，因為這些頁從來不會變臟。
?
任意的片段
你可以以片段的方式向你的二進制文件添加任何的數據，通過-sectcreate鏈接參數。這就是你怎樣添加info.plist到一個獨立的二進制文件。Info.plist的數據需要被放在_TEXT段的_info_plist片段。你可以使用連接器的命令-sectcreate segname sectname file來實現：
-Wl,-sectcreate,__TEXT,__info_plist,path/to/Info.plist?
同樣的，-sectalign也致命了對齊方式。如果你添加一個全新的段，通過-segprot來制定數據的保護方式。這些都是在連接器中的幫助手冊中的。
?
你能夠到達在/usr/include/mach-o/getsect.h中定義的函數在二進制文件中的那些片段，通過使用getsectdata()，它將會返回片段數據的指針和大小。
?
Mch-o
?
在OS X和iOS中可執行文件是Mach-o格式的:
% file a.out ?
a.out: Mach-O 64-bit executable x86_64?
?對于GUI的程序來說也是這樣:
% file /Applications/Preview.app/Contents/MacOS/Preview ?
/Applications/Preview.app/Contents/MacOS/Preview: Mach-O 64-bit executable x86_64?
你可以從這里找到關于mach-o文件格式的詳細資料。
?
我們可以使用otool來看一看mach-o文件的頭部。這說明了這個文件是什么，和怎樣被加載的。我們將會使用-h參數來打印頭部信息。
% otool -v -h a.out ? ? ? ? ? a.out:?
Mach header?
? ? ? magic cputype cpusubtype ?caps ? ?filetype ncmds sizeofcmds ? ? ?flags?
MH_MAGIC_64 ?X86_64 ? ? ? ?ALL LIB64 ? ? EXECUTE ? ?16 ? ? ? 1296 ? NOUNDEFS DYLDLINK TWOLEVEL PIE?
?
cputype和cpusubtype指明了可執行文件的目標架構。ncmds和sizeofcmds將會加載一些命令，這些命令我們可以通過-l參數來查看:
% otool -v -l a.out | open -f?
a.out:?
Load command 0?
? ? ? cmd LC_SEGMENT_64?
? cmdsize 72?
? segname __PAGEZERO?
? ?vmaddr 0x0000000000000000?
? ?vmsize 0x0000000100000000?
...?
加載命令指明了文件的邏輯結構和文件在虛擬內存中的布局。絕大多數otool打印的信息都是從這些加載命令中來的。看一下Load comand 1部分，我們看到了initprot r-x,這指明了我們上面提到的數據保護模式：只讀并且可執行。
?
對于每一個段和每一個段中的片段，加載命令說明了它們會在內存中的位置和它們的保護模式，例如，這是關于__TEXT __text片段的輸出：
Section?
? sectname __text?
? ?segname __TEXT?
? ? ? addr 0x0000000100000f30?
? ? ? size 0x0000000000000037?
? ? offset 3888?
? ? ?align 2^4 (16)?
? ? reloff 0?
? ? nreloc 0?
? ? ? type S_REGULAR?
attributes PURE_INSTRUCTIONS SOME_INSTRUCTIONS?
?reserved1 0?
?reserved2 0?
我們的代碼將截止在0x100000f30.它在文件中的偏移量通常是3888。如果你看一下a.out的范匯編輸出。你能夠在0x100000f30處看到我們的代碼。
?
我們同樣可以看一下在可執行文件中，動態鏈接庫是怎樣使用的:
% otool -v -L a.out?
a.out:?
? ? /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 169.3.0)?
? ? time stamp 2 Thu Jan ?1 01:00:02 1970?
這是你能夠在二進制文件中的__printf符號鏈接將要用到的庫。
?
一個更復雜的例子
讓我們來看一個有三個文件的復雜的例子:
Foo.h:?
#import <Foundation/Foundation.h>?
@interface Foo : NSObject?
- (void)run;?
@end?
Foo.m:?
#import "Foo.h"?
@implementation Foo?
- (void)run?
{?
? ? NSLog(@"%@", NSFullUserName());?
}?
@end?
helloworld.m:?
#import "Foo.h"?
int main(int argc, char *argv[])?
{?
? ? @autoreleasepool {?
? ? ? ? Foo *foo = [[Foo alloc] init];?
? ? ? ? [foo run];?
? ? ? ? return 0;?
? ?}?
}?
編譯多個文件
非常明顯，我們現在有多個文件。所以我們需要對每一個文件調用clang來生成目標文件：
% xcrun clang -c Foo.m?
% xcrun clang -c helloworld.m?
我們從來不編譯頭文件。頭文件的目的是在實現文件中貢獻代碼，并通過這種方式來唄編譯。通過#import語句Foo.m和helloworld.m中都被插入了foo.h的內容。 我們得到了兩個文件：
% file helloworld.o Foo.o?
helloworld.o: Mach-O 64-bit object x86_64?
Foo.o: ? ? ? ?Mach-O 64-bit object x86_64?
為了生成可執行文件，我們需要鏈接這兩個目標文件和Foundation系統庫：
xcrun clang helloworld.o Foo.o -Wl,`xcrun --show-sdk- ? ?path`/System/Library/Frameworks/Foundation.framework/Foundation?
現在，我們可以運行我們的程序了。
?
符號表和鏈接
我們這個簡單的app是通過兩個目標文件合并到一起得到的。Foo.o包含了Foo類的實現，同事helloworld.o包含了調用Foo類方法run的main函數。 進一步，兩個文件都使用了Foundation庫。在helloworld.o中autorelease pool使用了這個庫，以簡潔的方式使用了libobjc.dylib中的Objctive-c運行時。它需要使用運行時的函數來發送消息調用。foo.o也是一樣的。
?
這些被形象的稱之為符號。我們可以把符號看成一些在運行時將會變成指針的東西。雖然實際上并不是這樣能夠。 每一個函數，全局變量，類等等都是通過符號的方式來使用的。當我們為可執行文件連接一個目標文件，連接器將會按需要決定目標文件和動態庫之間的所有符號。 可執行文件和目標文件都有一個符號表來存儲這些符號。如果你使用nm工具來查看一下helloworld.o你會發現：
% xcrun nm -nm helloworld.o?
? ? ? ? ? ? ? ? ?(undefined) external _OBJC_CLASS_$_Foo?
0000000000000000 (__TEXT,__text) external _main?
? ? ? ? ? ? ? ? ?(undefined) external _objc_autoreleasePoolPop?
? ? ? ? ? ? ? ? ?(undefined) external _objc_autoreleasePoolPush?
? ? ? ? ? ? ? ? ?(undefined) external _objc_msgSend?
? ? ? ? ? ? ? ? ?(undefined) external _objc_msgSend_fixup?
0000000000000088 (__TEXT,__objc_methname) non-external L_OBJC_METH_VAR_NAME_?
000000000000008e (__TEXT,__objc_methname) non-external L_OBJC_METH_VAR_NAME_1?
0000000000000093 (__TEXT,__objc_methname) non-external L_OBJC_METH_VAR_NAME_2?
00000000000000a0 (__DATA,__objc_msgrefs) weak private external l_objc_msgSend_fixup_alloc?
00000000000000e8 (__TEXT,__eh_frame) non-external EH_frame0?
0000000000000100 (__TEXT,__eh_frame) external _main.eh?
這就是文件中所有的符號鏈接。__OBJC_CLASS_$_Foo是類Foo的符號鏈接。它還沒有被決定成Foo類的外部鏈接。外部表示它對不是私有的。與此相反non-external表明符號鏈接對于特定的文件是私有的。 我們的helloworld.o文件引用了Foo類，但是并沒有實現它。于是符號最后以未確定結尾。
?
下面，main函數同樣是外部鏈接，因為它需要能夠被外部看到并被調用。無論怎樣，main函數是在helloworld中實現的。并且放在了地址0，和放在__TEXT __text片段中。然后是四個objc運行時的函數。它們同樣是未定義的，需要連接器來決定。
?
我們再來看看Foo.o文件:
% xcrun nm -nm Foo.o?
0000000000000000 (__TEXT,__text) non-external -[Foo run]?
? ? ? ? ? ? ? ? ?(undefined) external _NSFullUserName?
? ? ? ? ? ? ? ? ?(undefined) external _NSLog?
? ? ? ? ? ? ? ? ?(undefined) external _OBJC_CLASS_$_NSObject?
? ? ? ? ? ? ? ? ?(undefined) external _OBJC_METACLASS_$_NSObject?
? ? ? ? ? ? ? ? ?(undefined) external ___CFConstantStringClassReference?
? ? ? ? ? ? ? ? ?(undefined) external __objc_empty_cache?
? ? ? ? ? ? ? ? ?(undefined) external __objc_empty_vtable?
000000000000002f (__TEXT,__cstring) non-external l_.str?
0000000000000060 (__TEXT,__objc_classname) non-external L_OBJC_CLASS_NAME_?
0000000000000068 (__DATA,__objc_const) non-external l_OBJC_METACLASS_RO_$_Foo?
00000000000000b0 (__DATA,__objc_const) non-external l_OBJC_$_INSTANCE_METHODS_Foo?
00000000000000d0 (__DATA,__objc_const) non-external l_OBJC_CLASS_RO_$_Foo?
0000000000000118 (__DATA,__objc_data) external _OBJC_METACLASS_$_Foo?
0000000000000140 (__DATA,__objc_data) external _OBJC_CLASS_$_Foo?
0000000000000168 (__TEXT,__objc_methname) non-external L_OBJC_METH_VAR_NAME_?
000000000000016c (__TEXT,__objc_methtype) non-external L_OBJC_METH_VAR_TYPE_?
00000000000001a8 (__TEXT,__eh_frame) non-external EH_frame0?
00000000000001c0 (__TEXT,__eh_frame) non-external -[Foo run].eh?
末五行指出_OBJC_CLASS_$_Foo是一個已定義的并且是個外部符號，同時包含Foo的實現。 Foo.o也有未定義的符號。最前面的是它使用過的NSFullUserName（），NSLog（）和NSObject。 當我們連接著兩個文件還有Foundation庫的時候，將會確定這些在動態鏈接庫中的符號。臨界期記錄了輸出文件以來特定的動態鏈接庫和它們的位置。這就是NSFullName()等將會發生的事情。
?
我們可以看一下最后的執行文件a.out的符號表，就能夠發現連接器是怎樣確定這些符號的：
% xcrun nm -nm a.out ?
? ? ? ? ? ? ? ? ?(undefined) external _NSFullUserName (from Foundation)?
? ? ? ? ? ? ? ? ?(undefined) external _NSLog (from Foundation)?
? ? ? ? ? ? ? ? ?(undefined) external _OBJC_CLASS_$_NSObject (from CoreFoundation)?
? ? ? ? ? ? ? ? ?(undefined) external _OBJC_METACLASS_$_NSObject (from CoreFoundation)?
? ? ? ? ? ? ? ? ?(undefined) external ___CFConstantStringClassReference (from CoreFoundation)?
? ? ? ? ? ? ? ? ?(undefined) external __objc_empty_cache (from libobjc)?
? ? ? ? ? ? ? ? ?(undefined) external __objc_empty_vtable (from libobjc)?
? ? ? ? ? ? ? ? ?(undefined) external _objc_autoreleasePoolPop (from libobjc)?
? ? ? ? ? ? ? ? ?(undefined) external _objc_autoreleasePoolPush (from libobjc)?
? ? ? ? ? ? ? ? ?(undefined) external _objc_msgSend (from libobjc)?
? ? ? ? ? ? ? ? ?(undefined) external _objc_msgSend_fixup (from libobjc)?
? ? ? ? ? ? ? ? ?(undefined) external dyld_stub_binder (from libSystem)?
0000000100000000 (__TEXT,__text) [referenced dynamically] external __mh_execute_header?
0000000100000e50 (__TEXT,__text) external _main?
0000000100000ed0 (__TEXT,__text) non-external -[Foo run]?
0000000100001128 (__DATA,__objc_data) external _OBJC_METACLASS_$_Foo?
0000000100001150 (__DATA,__objc_data) external _OBJC_CLASS_$_Foo?
我們發現Foundation和Objctive-C運行時的一些符號依然是未確定的。但是符號表中，記錄了怎樣去確定它們。例如那些它們可以去查找的動態鏈接庫。
?
可執行文件一樣也知道去哪找這些庫：
% xcrun otool -L a.out?
a.out:?
? ? /System/Library/Frameworks/Foundation.framework/Versions/C/Foundation (compatibility version 300.0.0, current version 1056.0.0)?
? ? /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1197.1.1)?
? ? /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation (compatibility version 150.0.0, current version 855.11.0)?
? ? /usr/lib/libobjc.A.dylib (compatibility version 1.0.0, current version 228.0.0)?
這些未定義的符號將會在運行時被dyld(1)確定。當我們執行程序的時候，dyld將會在Foundation中確定指向_NSFullUserName等的實現的指針，等等等等
?
我們可以再次使用nm來查看你這些符號在Foundation中的情況，實際上，如下：
% xcrun nm -nm `xcrun --show-sdk-path`/System/Library/Frameworks/Foundation.framework/Foundation | grep NSFullUserName?
0000000000007f3e (__TEXT,__text) external _NSFullUserName?
?
動態鏈接編輯器
這里有一些環境變量能幫助我們看一下dyld到底做了些什么。首先是DYLD_PRINT_LIBRARIES.如果設置了，dyld將會輸出已經加載的東戴鏈接庫：
% (export DYLD_PRINT_LIBRARIES=; ./a.out )?
dyld: loaded: /Users/deggert/Desktop/command_line/./a.out?
dyld: loaded: /System/Library/Frameworks/Foundation.framework/Versions/C/Foundation?
dyld: loaded: /usr/lib/libSystem.B.dylib?
dyld: loaded: /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation?
dyld: loaded: /usr/lib/libobjc.A.dylib?
dyld: loaded: /usr/lib/libauto.dylib?
[...]?
這顯示了七十多個在加載Foundation的時候加載的動態鏈接庫。這是因為Foundation庫也依賴于其他很多動態鏈接庫， 你可以運行：
?
% xcrun otool -L `xcrun --show-sdk-path`/System/Library/Frameworks/Foundation.framework/Foundation?
來查看五十多個Foundation依賴的庫。
?
dyld的共享緩存
?
當你構建一個真正的程序的時候，你將會鏈接各種各樣的庫。它們又會依賴其他的一些框架和動態鏈接庫。于是要加載的動態鏈接庫會非常多。同樣非獨立的符號也非常多。這里就會有成千上萬的符號要確定。這個工作將會話費很多時間——幾秒鐘。 為了優化這個過程，OS X和iOS上動態鏈接器使用了一個共享緩存，在/var/db/dyld/。對于每一種架構，操作系統有一個單獨的文件包含了絕大多數的動態鏈接庫，這些庫已經互相連接并且符號都已經確定。當一個Mach-o文件被加載的時候，動態鏈接器會首先檢查共享緩存，如果存在相應的庫就是用。每一個進程都把這個共享緩存映射到了自己的地址空間中。這個方法戲劇性的優化了OS X和iOS上程序的加載時間。
========
總結
以上是生活随笔為你收集整理的IOS可执行文件学习总结的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 软件调试学习摘录
- 下一篇： Kinect SDK V1.7 开发工具