最近在研究MiCO OS項(xiàng)目的時(shí)候，發(fā)現(xiàn)編譯目錄build下有一個(gè)xxxx.map文件，打開一看，感覺都是一些內(nèi)存段和符號信息，由此想到應(yīng)該是編譯鏈接過程中輸出的一些信息。之前沒有接觸過，今天就來學(xué)習(xí)一下map文件是個(gè)什么東西、有什么作用。
map文件片段：
Allocating common symbols
Common symbol size file
errno 0x4 d:/programs/micoder/compiler/arm-none-eabi-5_4-2016q2-20160622/win32/bin/../lib/gcc/arm-none-eabi/5.4.1/../../../../arm-none-eabi/lib/armv7e-m/fpu\libc_nano.a(lib_a-reent.o)
Discarded input sections
.text 0x00000000 0x0 ./build/mico-iot-module@mx1290@moc/libraries/App_IoT_Module.a(app_main.o)
.data 0x00000000 0x0 ./build/mico-iot-module@mx1290@moc/libraries/App_IoT_Module.a(app_main.o)
.bss 0x00000000 0x0 ./build/mico-iot-module@mx1290@moc/libraries/App_IoT_Module.a(app_main.o)
.comment 0x00000000 0x6f ./build/mico-iot-module@mx1290@moc/libraries/App_IoT_Module.a(app_main.o)
.ARM.attributes
0x00000000 0x39 ./build/mico-iot-module@mx1290@moc/libraries/App_IoT_Module.a(app_main.o)
.text 0x00000000 0x0 ./build/mico-iot-module@mx1290@moc/libraries/App_IoT_Module.a(mqtt_interface.o)
.data 0x00000000 0x0 ./build/mico-iot-module@mx1290@moc/libraries/App_IoT_Module.a(mqtt_interface.o)
.bss 0x00000000 0x0 ./build/mico-iot-module@mx1290@moc/libraries/App_IoT_Module.a(mqtt_interface.o)
.comment 0x00000000 0x6f ./build/mico-iot-module@mx1290@moc/libraries/App_IoT_Module.a(mqtt_interface.o)
.ARM.attributes
1 什么是Map文件？
簡單來說，map文件就是通過編譯器編譯之后，生成的程序、數(shù)據(jù)及IO空間信息的一種映射文件，里面包含函數(shù)大小，入口地址等一些重要信息。從map文件我們可以了解到：
- 程序各區(qū)段的尋址是否正確
- 程序各區(qū)段的size，即目前存儲(chǔ)器的使用量
- 程序中各個(gè)symbol的地址
- 各個(gè)symbol在存儲(chǔ)器中的順序關(guān)系（這在調(diào)試時(shí)很有用）
- 各個(gè)程序文件的存儲(chǔ)用量
2 如何生成？
生成map文件是鏈接器ld的功能，有兩種方式可以生成map文件：
通過gcc參數(shù)-Wl,-Map,：
gcc -o helloworld helloworld.c -Wl,-Map,file_name.map通過ld參數(shù)-Map：
ld -Map file_name.map helloworld.o -o helloworld
3 有啥用？
做出可執(zhí)行文件下載到機(jī)器上，你如何知道程序段或數(shù)據(jù)段會(huì)不會(huì)太大，會(huì)不會(huì)超過ROM或RAM的size？你如何知道Link腳本有沒有寫錯(cuò)，每個(gè)程序區(qū)段都確實(shí)尋址到符合機(jī)器的存儲(chǔ)器設(shè)定？當(dāng)然你可以下載進(jìn)機(jī)器運(yùn)行就知道了嗎？但是認(rèn)為負(fù)責(zé)整合的工程師一定要檢查下map文件，有些問題只會(huì)造成系統(tǒng)的不穩(wěn)定，而不會(huì)馬上死機(jī)，這種問題最麻煩。
4 例子
寫了一段簡單的代碼，測試一下map文件：
#include <stdio.h>
#include <unistd.h>
#include <pthread.h>
int g_var1;
char *g_var2 = "hello world !";
int test_func(int arg) {
static char *s_var1 = NULL;
static int s_var2 = 255;
int var = arg * 10;
return var;
}
static void *pthread_proc(void *arg)
{
/* 線程pthread開始運(yùn)行 */
printf("pthread start!\n");
/* 令主線程繼續(xù)執(zhí)行 */
sleep(2);
return NULL;
}
int main(int argc, char **argv) {
pthread_t tidp;
g_var1 = 100;
printf("%s\n", g_var2);
printf("main=%016llx, func=%016llx, var=%016llx\n", (long long)main, (long long)test_func, (long long)g_var2);
test_func(g_var1);
pthread_create(&tidp, NULL, pthread_proc, NULL);
pthread_join(tidp, NULL);
printf("exit !\n");
return 0;
}
程序基本包含代碼的所有關(guān)鍵點(diǎn)：全局變量、靜態(tài)變量、局部變量、函數(shù)、鏈接庫。執(zhí)行編譯命令gcc -o helloworld helloworld.c -Wl,-Map,helloworld.map -lpthread，生成map文件和可執(zhí)行文件。
程序執(zhí)行結(jié)果：
$ ./helloworld
hello world !
main=000055c70b2dd86e, func=000055c70b2dd82a, var=000055c70b2dd9c8
pthread start!
exit !
map文件片段1：
按需庫被包含以滿足文件 (符號) 引用
libpthread.so.0 /tmp/ccnK3bV5.o (pthread_create@@GLIBC_2.2.5)
libc.so.6 /tmp/ccnK3bV5.o (puts@@GLIBC_2.2.5)
分配公共符號
公共符號 大小 文件
g_var1 0x4 /tmp/ccnK3bV5.o
可以看到鏈接庫(libpthread)的引用符號(pthread_create函數(shù))、全局變量(g_var1)。
注意：靜態(tài)變量和靜態(tài)函數(shù)不會(huì)出現(xiàn)在map文件中！
map文件片段2：
.text 0x0000000000000700 0x2b /usr/lib/gcc/x86_64-linux-gnu/7/../../../x86_64-linux-gnu/Scrt1.o
0x0000000000000700 _start
.text 0x000000000000072b 0x0 /usr/lib/gcc/x86_64-linux-gnu/7/../../../x86_64-linux-gnu/crti.o
*fill* 0x000000000000072b 0x5
.text 0x0000000000000730 0xda /usr/lib/gcc/x86_64-linux-gnu/7/crtbeginS.o
.text 0x000000000000080a 0xfc /tmp/ccnK3bV5.o
0x000000000000080a test_func
0x000000000000084e main
可以看到函數(shù)test_func和main的信息，其地址與程序運(yùn)行時(shí)打印出的地址有必然聯(lián)系(最后一個(gè)字節(jié)相同)。理論上打印的地址和map中的地址(物理地址)應(yīng)該是一樣的，但由于Linux系統(tǒng)的虛擬地址機(jī)制，打印出來的是虛擬地址，但是地址排列是一致的，所以最后一個(gè)字節(jié)相同。
map文件片段3：
.bss 0x0000000000201028 0x18
*(.dynbss)
.dynbss 0x0000000000201028 0x0 /usr/lib/gcc/x86_64-linux-gnu/7/../../../x86_64-linux-gnu/Scrt1.o
*(.bss .bss.* .gnu.linkonce.b.*)
.bss 0x0000000000201028 0x0 /usr/lib/gcc/x86_64-linux-gnu/7/../../../x86_64-linux-gnu/Scrt1.o
.bss 0x0000000000201028 0x0 /usr/lib/gcc/x86_64-linux-gnu/7/../../../x86_64-linux-gnu/crti.o
.bss 0x0000000000201028 0x1 /usr/lib/gcc/x86_64-linux-gnu/7/crtbeginS.o
*fill* 0x0000000000201029 0x7
.bss 0x0000000000201030 0x8 /tmp/ccnK3bV5.o
.bss 0x0000000000201038 0x0 /usr/lib/x86_64-linux-gnu/libc_nonshared.a(elf-init.oS)
.bss 0x0000000000201038 0x0 /usr/lib/gcc/x86_64-linux-gnu/7/crtendS.o
.bss 0x0000000000201038 0x0 /usr/lib/gcc/x86_64-linux-gnu/7/../../../x86_64-linux-gnu/crtn.o
*(COMMON)
COMMON 0x0000000000201038 0x4 /tmp/ccnK3bV5.o
0x0000000000201038 g_var1
由于g_var1是未初始化的全局變量，應(yīng)該被分配在bss段，從map文件也可以驗(yàn)證這一點(diǎn)。
map文件片段4：
.data 0x0000000000201010 0x14 /tmp/ccnK3bV5.o
0x0000000000201010 g_var2
.rodata 0x00000000000009c8 0x50 /tmp/ccPjpRD1.o
同理，g_var2是初始化的全局變量，分配在數(shù)據(jù)段(.data)。g_var2的初始化數(shù)據(jù)“hello world !”放在只讀數(shù)據(jù)段(.rodata)。
以上~~~
