亚洲一区二三,亚洲福利视频网,国产精品视频第一区

peakflys

編譯器背后的小故事

工作當中遇到過好幾次比較詭異的問題，最后基本都是編譯器搗的鬼，在此總結一下，以供大家參考，不對之處希望踴躍拍磚(peakflys原創作品，轉載注明 )
編譯環境：GCC 3.4.5 20051201 (項目組早期代碼從04年開始的)，為了脫離實際項目代碼，下面僅用測試例子來反映基本一樣的問題。
例一：

/**

*\author peakflys

*\brief 演示編譯器“潛規則”

*/
#include <iostream>

#include <limits>
using namespace std;
typedef unsigned int DWORD;
typedef unsigned long QWORD;

int main()
{
    cout<<"max unsigned int : \t"<<numeric_limits<DWORD>::max()<<endl;
    cout<<"max unsigned long: \t"<<numeric_limits<QWORD>::max()<<endl;
    DWORD st1 = 4200000000,st2 = 100000000;
    QWORD i1 = st1 + st2; //或者直接就用4200000000 + 100000000
cout<<i1<<endl;
    return 0;
}

我服務器上的運行結果：

max unsigned int : 4294967295
max unsigned long: 18446744073709551615
5032704

如果在高級別的警告環境下，編譯會有溢出警告，而運行結果也證明了確實溢出了。
查看匯編如下：

0x0000000000400949 <main+101>:  movl   $0xfa56ea00,-0x18(%rbp)
0x0000000000400950 <main+108>:  movl   $0x5f5e100,-0x14(%rbp)
0x0000000000400957 <main+115>:  mov    -0x14(%rbp),%eax
0x000000000040095a <main+118>:  add    -0x18(%rbp),%eax
0x000000000040095d <main+121>:  mov    %eax,%eax
0x000000000040095f <main+123>:  mov    %rax,-0x10(%rbp)
0x0000000000400963 <main+127>:  mov    -0x10(%rbp),%rsi
0x0000000000400967 <main+131>:  mov    $0x600ed0,%edi
0x000000000040096c <main+136>:  callq  0x400748 <_ZNSolsEm@plt>

原來編譯器是先把st2值放在eax里，然后和st1相加，結果還是放在eax里，而eax是32位寄存器，自然溢出了……
修改代碼及運行結果如下：

/**

*\author peakflys

*\brief 演示編譯器“潛規則”

*/

#include <iostream>
#include <limits>
using namespace std;
typedef unsigned int DWORD;
typedef unsigned long QWORD;

int main()
{
    cout<<"max unsigned int : \t"<<numeric_limits<DWORD>::max()<<endl;
    cout<<"max unsigned long: \t"<<numeric_limits<QWORD>::max()<<endl;
    DWORD st1 = 4200000000,st2 = 100000000;
    QWORD i1 = (QWORD)st1 + st2;
    cout<<i1<<endl;
    return 0;
}

max unsigned int : 4294967295
max unsigned long: 18446744073709551615
4300000000

這次運行正確，直接disassemble，相加代碼匯編如下：

0x0000000000400949 <main+101>:  movl   $0xfa56ea00,-0x18(%rbp)
0x0000000000400950 <main+108>:  movl   $0x5f5e100,-0x14(%rbp)
0x0000000000400957 <main+115>:  mov    -0x18(%rbp),%edx
0x000000000040095a <main+118>:  mov    -0x14(%rbp),%eax
0x000000000040095d <main+121>:  lea    (%rdx,%rax,1),%rax
0x0000000000400961 <main+125>:  mov    %rax,-0x10(%rbp)
0x0000000000400965 <main+129>:  mov    -0x10(%rbp),%rsi
0x0000000000400969 <main+133>:  mov    $0x600ed0,%edi
0x000000000040096e <main+138>:  callq  0x400748 <_ZNSolsEm@plt>

可見這次編譯器動用了兩個寄存器edx和eax來做相加操作，結果在64為的rax里，自然不會溢出了。這個例子的原型是程序里處理玩家獲得經驗的經驗公式，本來很多經驗，最后只獲得了極少的經驗。
例二：

/**

*\author peakflys

*\brief 演示編譯器自動優化

*/

#include <iostream>
using namespace std;
class A
{
    public:
        A(const int _a) : a(a){}
        int a;
};
int main()
{
    cout<<"test1(const Class):\t";
    const A ca(100);
    A *pca = (A*)&ca;
    pca->a = 50;
    cout<<"initValue: 100"<<"\tconstValue:"<<ca.a<<"\tnonconstValue:"<<pca->a<<endl;

    cout<<"test2(const int):\t";
    const int a = 100;
    int *pi = (int *)&a;
    *pi = 50;
    cout<<"initValue: 100"<<"\tconstValue:"<<a<<"\tnonconstValue:"<<*pi<<endl;

    cout<<"test3(const string):\t";
    const string s("中國"); "
    char *ps = const_cast<char*> (s.c_str());
    strcpy(ps,"美國"); "
    cout<<"initValue: 中國"<<"\tconstValue:"<<s<<"\tnonconstValue:"<<ps<<endl;nd

    return 0;
}

運行結果如下：

test1(const Class):     initValue: 100  constValue:50   nonconstValue:50
test2(const int):       initValue: 100  constValue:100  nonconstValue:50
test3(const string):    initValue: 中國 constValue:美國 nonconstValue:美國

程序中強制去除const的代碼很粗暴，很ugly，但是實際使用中有時候不得不因為各種原因而使用這樣的代碼。上面例子中對于class類型(自定義的classA和系統的class string)和系統基本類型(上面的int)強制去掉棧對象的const屬性再做操作是可行的(這樣的const僅僅是編譯器操作的const，如果是字符串常量等實際常量區的對象強行操作，操作系統會發飆的……)，但是操作結果卻不一樣，查看匯編：

ump of assembler code for function main:
0x0000000000400b24 <main+0>:    push   %rbp
0x0000000000400b25 <main+1>:    mov    %rsp,%rbp
0x0000000000400b28 <main+4>:    push   %r12
0x0000000000400b2a <main+6>:    push   %rbx
0x0000000000400b2b <main+7>:    sub    $0x50,%rsp

***********************************test1*********************************************

0x0000000000400b2f <main+11>:   mov    $0x400e48,%esi
0x0000000000400b34 <main+16>:   mov    $0x601300,%edi
0x0000000000400b39 <main+21>:   callq  0x400940 <_ZStlsISt11char_traitsIcEERSt13basic_ostreamIcT_ES5_PKc@plt>
0x0000000000400b3e <main+26>:   lea    -0x30(%rbp),%rdi //ca的棧地址！
0x0000000000400b42 <main+30>:   mov    $0x64,%esi
0x0000000000400b47 <main+35>:   callq  0x400d36 <A> //調用A構造函數
0x0000000000400b4c <main+40>:   lea    -0x30(%rbp),%rax
0x0000000000400b50 <main+44>:   mov    %rax,-0x28(%rbp) //pca的棧地址！
0x0000000000400b54 <main+48>:   mov    -0x28(%rbp),%rax
0x0000000000400b58 <main+52>:   movl   $0x32,(%rax) //pca所地址(即ca)，賦值0x32(50)
0x0000000000400b5e <main+58>:   mov    -0x28(%rbp),%rax //從右向左壓棧，先取出pca值
0x0000000000400b62 <main+62>:   mov    (%rax),%r12d //取出pca所指內存值
0x0000000000400b65 <main+65>:   mov    -0x30(%rbp),%ebx //取出ca值
0x0000000000400b68 <main+68>:   mov    $0x400e5d,%esi //
0x0000000000400b6d <main+73>:   mov    $0x601300,%edi //壓棧esi、edi，裝備調用callq
0x0000000000400b72 <main+78>:   callq  0x400940 <_ZStlsISt11char_traitsIcEERSt13basic_ostreamIcT_ES5_PKc@plt>
0x0000000000400b77 <main+83>:   mov    %rax,%rdi
0x0000000000400b7a <main+86>:   mov    $0x400e6c,%esi
0x0000000000400b7f <main+91>:   callq  0x400940 <_ZStlsISt11char_traitsIcEERSt13basic_ostreamIcT_ES5_PKc@plt>
0x0000000000400b84 <main+96>:   mov    %rax,%rdi
0x0000000000400b87 <main+99>:   mov    %ebx,%esi
0x0000000000400b89 <main+101>:  callq  0x4008e0 <_ZNSolsEi@plt>
0x0000000000400b8e <main+106>:  mov    %rax,%rdi
0x0000000000400b91 <main+109>:  mov    $0x400e79,%esi
0x0000000000400b96 <main+114>:  callq  0x400940 <_ZStlsISt11char_traitsIcEERSt13basic_ostreamIcT_ES5_PKc@plt>
0x0000000000400b9b <main+119>:  mov    %rax,%rdi
0x0000000000400b9e <main+122>:  mov    %r12d,%esi
0x0000000000400ba1 <main+125>:  callq  0x4008e0 <_ZNSolsEi@plt>
0x0000000000400ba6 <main+130>:  mov    %rax,%rdi
0x0000000000400ba9 <main+133>:  mov    $0x4009a0,%esi
0x0000000000400bae <main+138>:  callq  0x400990 <_ZNSolsEPFRSoS_E@plt>

***********************************test2*********************************************

0x0000000000400bb3 <main+143>:  mov    $0x400e89,%esi
0x0000000000400bb8 <main+148>:  mov    $0x601300,%edi
0x0000000000400bbd <main+153>:  callq  0x400940 <_ZStlsISt11char_traitsIcEERSt13basic_ostreamIcT_ES5_PKc@plt>
0x0000000000400bc2 <main+158>:  movl   $0x64,-0x34(%rbp) //a地址，ox64(100)放入此處
0x0000000000400bc9 <main+165>:  lea    -0x34(%rbp),%rax
0x0000000000400bcd <main+169>:  mov    %rax,-0x20(%rbp) //pi地址，放入a地址
0x0000000000400bd1 <main+173>:  mov    -0x20(%rbp),%rax //取出pi地址
0x0000000000400bd5 <main+177>:  movl   $0x32,(%rax) //pi所指內容(即a)賦值50
0x0000000000400bdb <main+183>:  mov    -0x20(%rbp),%rax   //從右向左壓棧，先取出pi值
0x0000000000400bdf <main+187>:  mov    (%rax),%ebx //pi所指內存值
//此處沒有取a的值？？？
0x0000000000400be1 <main+189>:  mov    $0x400e5d,%esi //
0x0000000000400be6 <main+194>:  mov    $0x601300,%edi //壓棧esi、edi，裝備調用callq
0x0000000000400beb <main+199>:  callq  0x400940 <_ZStlsISt11char_traitsIcEERSt13basic_ostreamIcT_ES5_PKc@plt>
0x0000000000400bf0 <main+204>:  mov    %rax,%rdi
0x0000000000400bf3 <main+207>:  mov    $0x400e6c,%esi
0x0000000000400bf8 <main+212>:  callq  0x400940 <_ZStlsISt11char_traitsIcEERSt13basic_ostreamIcT_ES5_PKc@plt>
0x0000000000400bfd <main+217>:  mov    %rax,%rdi
0x0000000000400c00 <main+220>:  mov    $0x64,%esi
0x0000000000400c05 <main+225>:  callq  0x4008e0 <_ZNSolsEi@plt>
0x0000000000400c0a <main+230>:  mov    %rax,%rdi
0x0000000000400c0d <main+233>:  mov    $0x400e79,%esi
0x0000000000400c12 <main+238>:  callq  0x400940 <_ZStlsISt11char_traitsIcEERSt13basic_ostreamIcT_ES5_PKc@plt>
0x0000000000400c17 <main+243>:  mov    %rax,%rdi
0x0000000000400c1a <main+246>:  mov    %ebx,%esi
0x0000000000400c1c <main+248>:  callq  0x4008e0 <_ZNSolsEi@plt>
0x0000000000400c21 <main+253>:  mov    %rax,%rdi
0x0000000000400c24 <main+256>:  mov    $0x4009a0,%esi
0x0000000000400c29 <main+261>:  callq  0x400990 <_ZNSolsEPFRSoS_E@plt>

***********************************test3*********************************************

0x0000000000400c2e <main+266>:  mov    $0x400e9c,%esi
0x0000000000400c33 <main+271>:  mov    $0x601300,%edi
0x0000000000400c38 <main+276>:  callq  0x400940 <_ZStlsISt11char_traitsIcEERSt13basic_ostreamIcT_ES5_PKc@plt>
0x0000000000400c3d <main+281>:  lea    -0x29(%rbp),%rdi
0x0000000000400c41 <main+285>:  callq  0x4009b0 <_ZNSaIcEC1Ev@plt>
0x0000000000400c46 <main+290>:  lea    -0x29(%rbp),%rdx
0x0000000000400c4a <main+294>:  lea    -0x40(%rbp),%rdi
0x0000000000400c4e <main+298>:  mov    $0x400eb2,%esi
0x0000000000400c53 <main+303>:  callq  0x400960 <_ZNSsC1EPKcRKSaIcE@plt>
0x0000000000400c58 <main+308>:  lea    -0x29(%rbp),%rdi
0x0000000000400c5c <main+312>:  callq  0x400980 <_ZNSaIcED1Ev@plt>
0x0000000000400c61 <main+317>:  lea    -0x40(%rbp),%rdi
0x0000000000400c65 <main+321>:  callq  0x4008f0 <_ZNKSs5c_strEv@plt>
0x0000000000400c6a <main+326>:  mov    %rax,-0x48(%rbp)
0x0000000000400c6e <main+330>:  jmp    0x400c8e <main+362>
0x0000000000400c70 <main+332>:  mov    %rax,-0x58(%rbp)
0x0000000000400c74 <main+336>:  mov    -0x58(%rbp),%rbx
0x0000000000400c78 <main+340>:  lea    -0x29(%rbp),%rdi
0x0000000000400c7c <main+344>:  callq  0x400980 <_ZNSaIcED1Ev@plt>
0x0000000000400c81 <main+349>:  mov    %rbx,-0x58(%rbp)
0x0000000000400c85 <main+353>:  mov    -0x58(%rbp),%rdi
0x0000000000400c89 <main+357>:  callq  0x4009d0 <_Unwind_Resume@plt>
0x0000000000400c8e <main+362>:  mov    -0x48(%rbp),%rax
0x0000000000400c92 <main+366>:  mov    %rax,-0x18(%rbp)
0x0000000000400c96 <main+370>:  mov    -0x18(%rbp),%rax
0x0000000000400c9a <main+374>:  movl   $0xe58ebee7,(%rax)
0x0000000000400ca0 <main+380>:  movw   $0xbd9b,0x4(%rax)
0x0000000000400ca6 <main+386>:  movb   $0x0,0x6(%rax)
0x0000000000400caa <main+390>:  mov    $0x400eb9,%esi
0x0000000000400caf <main+395>:  mov    $0x601300,%edi
0x0000000000400cb4 <main+400>:  callq  0x400940 <_ZStlsISt11char_traitsIcEERSt13basic_ostreamIcT_ES5_PKc@plt>
0x0000000000400cb9 <main+405>:  mov    %rax,%rdi
0x0000000000400cbc <main+408>:  mov    $0x400e6c,%esi
0x0000000000400cc1 <main+413>:  callq  0x400940 <_ZStlsISt11char_traitsIcEERSt13basic_ostreamIcT_ES5_PKc@plt>
0x0000000000400cc6 <main+418>:  mov    %rax,%rdi
0x0000000000400cc9 <main+421>:  lea    -0x40(%rbp),%rsi
0x0000000000400ccd <main+425>:  callq  0x400970 <_ZStlsIcSt11char_traitsIcESaIcEERSt13basic_ostreamIT_T0_ES7_RKSbIS4_S5_T1_E@plt>
0x0000000000400cd2 <main+430>:  mov    %rax,%rdi
0x0000000000400cd5 <main+433>:  mov    $0x400e79,%esi
0x0000000000400cda <main+438>:  callq  0x400940 <_ZStlsISt11char_traitsIcEERSt13basic_ostreamIcT_ES5_PKc@plt>
0x0000000000400cdf <main+443>:  mov    %rax,%rdi
0x0000000000400ce2 <main+446>:  mov    -0x18(%rbp),%rsi
0x0000000000400ce6 <main+450>:  callq  0x400940 <_ZStlsISt11char_traitsIcEERSt13basic_ostreamIcT_ES5_PKc@plt>
0x0000000000400ceb <main+455>:  mov    %rax,%rdi
0x0000000000400cee <main+458>:  mov    $0x4009a0,%esi
0x0000000000400cf3 <main+463>:  callq  0x400990 <_ZNSolsEPFRSoS_E@plt>
0x0000000000400cf8 <main+468>:  mov    $0x0,%ebx
0x0000000000400cfd <main+473>:  lea    -0x40(%rbp),%rdi
0x0000000000400d01 <main+477>:  callq  0x400950 <_ZNSsD1Ev@plt>
0x0000000000400d06 <main+482>:  mov    %ebx,-0x4c(%rbp)
0x0000000000400d09 <main+485>:  jmp    0x400d29 <main+517>
0x0000000000400d0b <main+487>:  mov    %rax,-0x58(%rbp)
0x0000000000400d0f <main+491>:  mov    -0x58(%rbp),%rbx
0x0000000000400d13 <main+495>:  lea    -0x40(%rbp),%rdi
0x0000000000400d17 <main+499>:  callq  0x400950 <_ZNSsD1Ev@plt>
0x0000000000400d1c <main+504>:  mov    %rbx,-0x58(%rbp)
0x0000000000400d20 <main+508>:  mov    -0x58(%rbp),%rdi
0x0000000000400d24 <main+512>:  callq  0x4009d0 <_Unwind_Resume@plt>
0x0000000000400d29 <main+517>:  mov    -0x4c(%rbp),%eax
0x0000000000400d2c <main+520>:  add    $0x50,%rsp
0x0000000000400d30 <main+524>:  pop    %rbx
0x0000000000400d31 <main+525>:  pop    %r12
0x0000000000400d33 <main+527>:  leaveq
0x0000000000400d34 <main+528>:  retq

因test1和test3基本原理一樣，故上面匯編注釋只有test1和test2的，從上面匯編可以看出，編譯器調用cout時，參數入棧是從右向左的，對于test1是取出pca所指內存值入棧，再取ca所指內存值入棧，然后調用cout輸出。但是test2入棧的卻只有pi所指內存值，i并沒有入棧。匯編沒顯示，個人認為應該是編譯器在匯編時就做了優化，把cout中的常量a直接替換掉了。這種錯誤在實際項目中顯現出的問題很詭異，剛開始也很難查，所以強轉基本類型const時注意這種情況。
例三、待續……
(peakflys原創作品，轉載注明 )

posted on 2012-07-27 17:08 peakflys 閱讀(3576) 評論(4) 編輯收藏引用所屬分類: C++

第二個示例,應該是int常量和object(string也算object)常量不同的原因, 好比值類型與引用類型.
int可以放到寄存器中,作為常量當然可以直接替換.
而object需要占用內存空間,const只是限制對object的修改,強轉之后就去除了這個限制. 回復更多評論

# re: 編譯器背后的小故事 2012-07-29 14:46 zgpxgame

s1，s2是同類型，不會發生隱式類型轉換，結果當然也是同類型的而溢出，隱式類型轉換發生在賦值時

strcpy(ps,"美國") 如果只是試驗，倒也關系不大，實際中這樣可能導致問題回復更多評論

# re: 編譯器背后的小故事 2012-07-30 10:48 peakflys

@ntest 而object需要占用內存空間？？？
這位仁兄的意思是const int 沒有內存的占用，只有寄存器的占用？上面例二加上匯編碼是為了說明，const int入棧時沒有從內存取值，應該是編譯器優化直接從類似的符號表(同C中的define一樣)里取出數值。回復更多評論

# re: 編譯器背后的小故事 2012-07-30 11:01 peakflys

@zgpxgame
例一的結果自然是發生在隱式轉換之前的值溢出，但關鍵應該是上面提到的GCC編譯器做運算時如果后面運算值沒有超過32位的，都會用32位寄存器做運算，只有你運算值本身有大于32位的或者程序中強制轉換成大于32位的(如例一后來改的那樣)，編譯器才會有64位寄存器的參與。就如同如果上面是把兩個unsigned short的最大值，即65535+65535賦給一個unsigned int值，程序運行正常，不會發生溢出。
PS string強轉去除const屬性，在實際應用中會出現，但是一般項目中都不會強制改變它的內容，上面例二僅僅是測試類常量和基本值常量直接些許的差別。回復更多評論

刷新評論列表

只有注冊用戶登錄后才能發表評論。


相關文章: SGI STL中默認Allocator為何變為new_allocator？以題論道----關于虛函數的一些解讀從一道面試題來闡釋一個普遍的認知誤區關于最優無限循環的考證由段錯誤引申出的緩沖區溢出攻擊分析小議c++之回調編譯器背后的小故事

網站導航: 博客園 IT新聞 BlogJava 博問 Chat2DB 管理

<

2012年7月

>

日

一

二

三

四

五

六

24

25

26

27

28

29

30

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

29

30

31

1

2

3

4

統計

隨筆 - 23
文章 - 18
評論 - 119
引用 - 0

公告

人不淡定的時候，就愛表現出來，敲代碼如此，偶爾的靈感亦如此……

# re: 編譯器背后的小故事 2012-07-28 08:22 ntest

# re: 編譯器背后的小故事 2012-07-29 14:46 zgpxgame

# re: 編譯器背后的小故事 2012-07-30 10:48 peakflys

# re: 編譯器背后的小故事 2012-07-30 11:01 peakflys

青青草原综合久久大伊人导航_色综合久久天天综合_日日噜噜夜夜狠狠久久丁香五月_热久久这里只有精品

編譯器背后的小故事

評論

導航

統計

公告

常用鏈接

留言簿(4)

隨筆分類

隨筆檔案

文章檔案

搜索

最新評論

閱讀排行榜

評論排行榜