gifty

全局/靜態(tài)變量內(nèi)存布局

測試程序：

#include

#include

using namespace std;

static int gs_num[53];

char g_buf1[190];

char g_buf2[232];

char g_buf3[] = "That's really a test!";

static char gs_buf1[233];

class Base

{

public:

Base()

{

memset(buf, 1, 100);

}

~Base()

{

}

private:

char buf[100];

};

Base g_base;

static Base gs_base;

void func()

{

static int s1[10];

static char s2[16] = "fs";

static int s3[20] = {15};

s1[10] = 3;

int a = s1[0]+ s2[0];

}

int main()

{

static int a[10] = {3};

static int b[10] = {4};

//func();

static Base base;

static char temp[100];

static char temp1[39];

static Base base1;

int c = a[0] + b[0];

cout<gs_buf1[0] = 'a';

return 0;

}

內(nèi)存布局

在main入口處設(shè)置斷點(diǎn)后內(nèi)存布局如下：

0x8049160 : 1952540756 1914729255 1819042149 543236217

0x8049170 : 1953719668 33 0 0

0x8049180 <_ZZ4mainE1b>: 4 0 0 0

0x8049190 <_ZZ4mainE1b+16>: 0 0 0 0

0x80491a0 <_ZZ4mainE1b+32>: 0 0 0 0

0x80491b0: 0 0 0 0

0x80491c0 <_ZZ4mainE1a>: 3 0 0 0

0x80491d0 <_ZZ4mainE1a+16>: 0 0 0 0

0x80491e0 <_ZZ4mainE1a+32>: 0 0 29542 0

0x80491f0 <_ZZ4funcvE2s2+8>: 0 0 0 0

0x8049200 <_ZSt4cout@@GLIBCXX_3.4>: 3086816908 3086816928 6 0

0x8049210 <_ZSt4cout@@GLIBCXX_3.4+16>: 4098 0 0 0

0x8049220 <_ZSt4cout@@GLIBCXX_3.4+32>: 0 0 0 0

0x8049230 <_ZSt4cout@@GLIBCXX_3.4+48>: 0 0 0 0

0x8049240 <_ZSt4cout@@GLIBCXX_3.4+64>: 0 0 0 0

0x8049250 <_ZSt4cout@@GLIBCXX_3.4+80>: 0 0 0 0

0x8049260 <_ZSt4cout@@GLIBCXX_3.4+96>: 0 0 8 134517288

0x8049270 <_ZSt4cout@@GLIBCXX_3.4+112>: 3086833084 0 0 3086827968

0x8049280 <_ZSt4cout@@GLIBCXX_3.4+128>: 3086829728 3086830428 3086830420 0

0x8049290 : 0 0 0 0

0x80492a0 : 0 0 0 0

0x80492b0 : 0 0 0 0

0x80492c0 : 0 0 0 0

0x80492d0 : 0 0 0 0

0x80492e0 : 0 0 0 0

0x80492f0 : 0 0 0 0

0x8049300 : 0 0 0 0

0x8049310 : 0 0 0 0

0x8049320 : 0 0 0 0

0x8049330 : 0 0 0 0

0x8049340 : 0 0 0 0

0x8049350 : 0 0 0 0

0x8049360 : 0 0 0 0

0x8049370 : 0 0 0 0

0x8049380 : 0 0 0 0

0x8049390 : 0 0 0 0

0x80493a0 : 0 0 0 0

0x80493b0 : 0 0 0 0

0x80493c0 : 0 0 0 0

0x80493d0 : 0 0 0 0

0x80493e0 : 0 0 0 0

0x80493f0 : 0 0 0 0

0x8049400 : 0 0 0 0

0x8049410 : 0 0 0 0

0x8049420 : 0 0 0 0

0x8049430 : 0 0 0 0

0x8049440 : 0 0 0 0

0x8049450: 0 0 0 0

0x8049460 : 16843009 16843009 16843009 16843009

0x8049470 : 16843009 16843009 16843009 16843009

0x8049480 : 16843009 16843009 16843009 16843009

0x8049490 : 16843009 16843009 16843009 16843009

0x80494a0 : 16843009 16843009 16843009 16843009

0x80494b0 : 16843009 16843009 16843009 16843009

0x80494c0 : 16843009 0 0 0

0x80494d0: 0 0 0 0

0x80494e0 <_ZL7gs_base>: 16843009 16843009 16843009 16843009

0x80494f0 <_ZL7gs_base+16>: 16843009 16843009 16843009 16843009

0x8049500 <_ZL7gs_base+32>: 16843009 16843009 16843009 16843009

0x8049510 <_ZL7gs_base+48>: 16843009 16843009 16843009 16843009

0x8049520 <_ZL7gs_base+64>: 16843009 16843009 16843009 16843009

0x8049530 <_ZL7gs_base+80>: 16843009 16843009 16843009 16843009

0x8049540 <_ZL7gs_base+96>: 16843009 0 0 0

0x8049550 <_ZGVZ4mainE5base1>: 0 0 0 0

0x8049560 <_ZL7gs_buf1>: 0 0 0 0

0x8049570 <_ZL7gs_buf1+16>: 0 0 0 0

0x8049580 <_ZL7gs_buf1+32>: 0 0 0 0

0x8049590 <_ZL7gs_buf1+48>: 0 0 0 0

0x80495a0 <_ZL7gs_buf1+64>: 0 0 0 0

---Type to continue, or q to quit---

0x80495b0 <_ZL7gs_buf1+80>: 0 0 0 0

0x80495c0 <_ZL7gs_buf1+96>: 0 0 0 0

0x80495d0 <_ZL7gs_buf1+112>: 0 0 0 0

0x80495e0 <_ZL7gs_buf1+128>: 0 0 0 0

0x80495f0 <_ZL7gs_buf1+144>: 0 0 0 0

0x8049600 <_ZL7gs_buf1+160>: 0 0 0 0

0x8049610 <_ZL7gs_buf1+176>: 0 0 0 0

0x8049620 <_ZL7gs_buf1+192>: 0 0 0 0

0x8049630 <_ZL7gs_buf1+208>: 0 0 0 0

0x8049640 <_ZL7gs_buf1+224>: 0 0 0 0

0x8049650: 0 0 0 0

0x8049660 <_ZZ4mainE5base1>: 0 0 0 0

0x8049670 <_ZZ4mainE5base1+16>: 0 0 0 0

0x8049680 <_ZZ4mainE5base1+32>: 0 0 0 0

0x8049690 <_ZZ4mainE5base1+48>: 0 0 0 0

0x80496a0 <_ZZ4mainE5base1+64>: 0 0 0 0

0x80496b0 <_ZZ4mainE5base1+80>: 0 0 0 0

0x80496c0 <_ZZ4mainE5base1+96>: 0 0 0 0

0x80496d0: 0 0 0 0

0x80496e0 <_ZZ4mainE5temp1>: 0 0 0 0

0x80496f0 <_ZZ4mainE5temp1+16>: 0 0 0 0

0x8049700 <_ZZ4mainE5temp1+32>: 0 0 0 0

0x8049710: 0 0 0 0

0x8049720 <_ZZ4mainE4base>: 0 0 0 0

0x8049730 <_ZZ4mainE4base+16>: 0 0 0 0

0x8049740 <_ZZ4mainE4base+32>: 0 0 0 0

0x8049750 <_ZZ4mainE4base+48>: 0 0 0 0

0x8049760 <_ZZ4mainE4base+64>: 0 0 0 0

0x8049770 <_ZZ4mainE4base+80>: 0 0 0 0

0x8049780 <_ZZ4mainE4base+96>: 0 0 0 0

0x8049790: 0 0 0 0

0x80497a0 <_ZZ4funcvE2s1>: 0 0 0 0

0x80497b0 <_ZZ4funcvE2s1+16>: 0 0 0 0

0x80497c0 <_ZZ4funcvE2s1+32>: 0 0 0 0

0x80497d0: 0 0 0 0

0x80497e0: 0 0 0 0

0x80497f0: 0 0 0 0

0x8049800: 0 0 0 0

0x8049810: 0 0 0 0

0x8049820: 0 0 0 0

0x8049830: 0 0 0 0

0x8049840: 0 0 0 0

0x8049850: 0 0 0 0

分析結(jié)果：

全局變量與靜態(tài)變量的唯一區(qū)別在于鏈接屬性，全局變量為外部鏈接屬性，全局靜態(tài)變量（類內(nèi)部的靜態(tài)變量）為內(nèi)部鏈接屬性，函數(shù)內(nèi)部的靜態(tài)變量無鏈接屬性。

注：對于類內(nèi)部的靜態(tài)變量，類名相當(dāng)于一個命名空間，而全局靜態(tài)變量的命名空間為：：（全局命名空間），所以它們本質(zhì)上無差別!

全局變量和靜態(tài)變量內(nèi)存布局基本相同，這里一并考慮。

全局/靜態(tài)變量的內(nèi)存分配主要是遵循一個大的原則，將初始化的和未初始化的變量分開存放，初始化的變量被放在全局?jǐn)?shù)據(jù)區(qū)，未初始化的變量放在BSS段，這樣有一個好處，BSS段在文件中是沒有大小的，只有一個地址，所有未初始化的全局靜態(tài)變量都指向這個地址，這樣可以減小文件的大小。而在運(yùn)行時，才會為BSS段分配內(nèi)存空間，并且全部初始化為0，所以未初始化的全局/靜態(tài)變量載入內(nèi)存后，默認(rèn)值為0。

然后我們看內(nèi)存布局：

前面4個變量依次是，g_buf3，_ZZ4mainE1b，_ZZ4mainE1a和_ZZ4funcvE2s2，編譯器在編譯時為了防止名稱沖突，會對變量函數(shù)名進(jìn)行名稱修飾，linux下可用c++filt工具進(jìn)行還原。

還原后的變量依次是：

g_buf3，main函數(shù)中的靜態(tài)變量b、a和func中的靜態(tài)變量s2。

這4個是初始化了的全局/靜態(tài)變量，所以被放在全局初始化區(qū)，這里我們得出以下幾點(diǎn)結(jié)論。

1、可以發(fā)現(xiàn)s2和s3都被初始化了，可是只有s2被分配內(nèi)存空間，而s3并未分配內(nèi)存空間，這是因為linux中為靜態(tài)變量分配內(nèi)存是根據(jù)該變量是否被使用來判斷的，如果一個靜態(tài)變量定義后，未發(fā)現(xiàn)它被其它變量引用了，將不會為其分配內(nèi)存空間。

2、對于全局變量，不管它是否被使用了，都會為其分配內(nèi)存空間。

3、在函數(shù)中的靜態(tài)變量，在內(nèi)存中的順序恰恰和它們在函數(shù)中的聲明順序相反（目前尚不知這樣做的原因）。

這里有一個疑問，g_base和gs_base這兩個變量被初始化了，為什么它們被放在未初始化的全局?jǐn)?shù)據(jù)區(qū)。這是因為g_base和gs_base這兩個變量是在運(yùn)行時通過調(diào)用構(gòu)造函數(shù)被初始化的，在編譯時我們是無法知道它們的值的，所以在編譯時它們也被放在了BSS段。所以這里得出結(jié)論：

4、全局/靜態(tài)類變量在內(nèi)存中被放在未初始化數(shù)據(jù)區(qū)。

下面我們看看未初始化數(shù)據(jù)區(qū)里面的變量，依次是

g_buf1、g_buf2、g_base、gs_base、main函數(shù)的base1、temp1、base，func函數(shù)的s1。

可以看到g_base、gs_base值不為0，而base1，base的值為0，因為我的斷點(diǎn)是在main函數(shù)入口處設(shè)置的，所以全局類變量的構(gòu)造函數(shù)已被調(diào)用過了，而main函數(shù)內(nèi)的類變量的構(gòu)造函數(shù)尚未調(diào)用，但是它們的內(nèi)存空間已被分配，這印證了以上結(jié)論4。

posted @ 2011-05-07 15:52 gifty 閱讀(882) | 評論 (0) | 編輯 收藏

GCC預(yù)編譯頭技術(shù)

最近在弄GCC的預(yù)編譯頭，用C++開發(fā)工程最難以忍受的就是烏龜似地的編譯速度，用VC開發(fā)工程的時候，VC會默認(rèn)幫我們引入預(yù)編譯頭，那么GCC呢？其實(shí)GCC也是支持預(yù)編譯頭得， http://lych.yo2.cn/articles/淺談gcc預(yù)編譯頭技術(shù).html 這篇文章就詳細(xì)講解了如何GCC下預(yù)編譯頭得一些知識, 所以具體如何在GCC中加入預(yù)編譯頭,大家可以參考這篇文章。

在給GCC添加預(yù)編譯頭時也遇到了一些問題，并且對C++/C的編譯有了一些新的認(rèn)識！

很多在linux下寫程序的人都應(yīng)該看過《和我一起寫Makefile》這篇文章，里面講過如何利用GCC的-MM選項自動生成依賴：

%.d: %.cpp
@$(GPP) -MM $(INCLUDE) $< > $@.tmp;\
sed 's,\($*\)\.o[ :]*,\1.o $@ : ,g' < $@.tmp > $@;\
rmf $@.tmp

這里利用了一個模式規(guī)則，將CPP文件依賴的頭文件寫到一個.d文件中，執(zhí)行Makefile時我們只需要include這些.d文件，GCC就會根據(jù)里面的依賴關(guān)系來生成對應(yīng)的.o文件了！
但是實(shí)際上GCC的自動推導(dǎo)能力非常強(qiáng)大，我們其實(shí)只需要寫下一條這樣的模式就可以了，
%.o:%.cpp
@$(GPP) $(CPPFLAGS) $< $(INCLUDE)

GCC就會自動推導(dǎo)出CPP文件所需要依賴的頭文件進(jìn)行編譯了！

如果你在自己的工程中加入了預(yù)編譯頭，你就必須使用下面一種模式。
舉個例子，比如你們工程開發(fā)了一些基礎(chǔ)庫，已經(jīng)比較穩(wěn)定了，除了一些少量的BUG FIX外，很少需要修改，當(dāng)你通過源碼形式引用的時候，你當(dāng)然不希望每次編譯的時候都去編譯
這些基礎(chǔ)庫，如是你決定將他們加入預(yù)編譯頭中去，但是當(dāng)你使用第一種方式寫Makefile的時候，你發(fā)現(xiàn)被你加入到預(yù)編譯頭中的頭文件還是被重復(fù)編譯了，因為-MM選項會把你CPP文件
依賴的非系統(tǒng)頭文件全部放在對應(yīng)的.d文件中。但是當(dāng)你使用第二種Makefile時，GCC看到一個預(yù)編譯頭后，他不會按照常規(guī)的方式將它展開，而是回去尋找對應(yīng)的.gch文件，然后進(jìn)行編譯，
如果你想一探究竟的話,編譯加上-H選項就可以看出其中的差異了！

這樣生成的預(yù)編譯頭如果要使用的話，需要和編譯CPP文件使用相同的選項，否則后出現(xiàn)一些奇怪的編譯錯誤，我的做法是寫一個預(yù)編譯頭得模式：

%.h.gch:%.h
$(GPP) $(CPPFLAGS) $< $(INCLUDE)

posted @ 2011-05-02 15:50 gifty 閱讀(1968) | 評論 (0) | 編輯 收藏