//From:http://www.cnblogs.com/chenchenluo/archive/2012/04/02/2421457.html
最近在看於淵的一個操作系統的實現，在第五章的時候彙編和C 同時使用時碰到了問題：代碼如下
foo.c
extern choose
[section .data]
num1st dd 3
num2nd dd 4
[section .text]
global _start
global myprint
_start:
push num2nd
push num1st
call choose
add esp,4
mov ebx,0
mov eax,1
int 0x80
myprint:
mov edx,[esp + 8]
mov ecx,[esp + 4]
mov ebx,1
mov eax,4
int 0x80
ret
void myprint(char* msg,int len);
int choose (int a,int b)
{
if( a >= b )
{
myprint("the 1st one \n",13);
} else {
myprint("the 2nd one\n",13);
}
return 0;
}1 nasm -f elf foo.s -o foo.o
2 gcc -c bar.c -o bar.o
3 ld -s -o foobar bar.o foo.o
彙編語言用nasm編寫並用nasm編譯器編譯，而C語言用的是gcc編譯，這些都沒有問題，但是在鏈接的時候出錯了，提示如下：
ld: i386 architecture of input file `foo.o' is incompatible with i386:x86-64 output
google了一下，意思就是nasm 編譯產生的是32位的目標代碼，gcc 在64位平臺上默認產生的是64位的目標代碼，這兩者在鏈接的時候出錯，gcc在64位平臺上默認以64位的方式鏈接。
這樣在解決的時候就會有兩種解決方案：
<1> 讓gcc 產生32位的代碼，並在鏈接的時候以32位的方式進行鏈接
在這種情況下只需要修改編譯和鏈接指令即可，具體如下：
1 nasm -f elf foo.s -o foo.o
2 gcc -m32 -c bar.c -o bar.o
3 ld -m elf_i386 -s -o foobar foo.o bar.o
具體的-m32 和 -m elf_i386 請自行查閱gcc （man gcc）
參考地址：http://bbs.chinaunix.net/thread-2018497-1-1.html
如果你是高版本的gcc（可能是由於更新內核造成的），可能簡單的使用-m32 的時候會提示以下錯誤（使用別人的歷程，自己未曾遇到）：
> In file included from /usr/include/stdio.h:28:0,> from test.c:1:> /usr/include/features.h:323:26: fatal error: bits/predefs.h: No such file or directory> compilation terminated.
這應該是缺少構建32位可執行程序缺少的包，使用以下指令安裝：sudo apt-get install libc6-dev-i386此時應該就沒有什麼問題了。
參考地址：http://aaronbonner.tumblr.com/post/14969163463/cross-compiling-to-32bit-with-gcc
<2> 讓nasm以64位的方式編譯產生目標代碼，並讓gcc的連接器以默認的方式鏈接
但是第二種方法並不是僅僅更改nasm的編譯方式那麼簡單，因爲64位平臺跟32位平臺有很大的不同，包括參數的傳遞，指令集等。所以如果怕麻煩的話完全可以使用第一種方法，讓gcc產生32位的目標代碼，因爲32位的代碼可以運行在64位的平臺上，這應該就是所謂的向上兼容。不過64位將來應該會是主流，所以研究一下還是很有必要的。
首先對gcc 產生的32位與64位的彙編語言進行對比：
1 gcc -m32 -S -o bar.s -c bar.c 2 3 4 choose: 5 .LFB0: 6 .cfi_startproc 7 pushl �p 8 .cfi_def_cfa_offset 8 9 .cfi_offset 5, -8 10 movl %esp, �p 11 .cfi_def_cfa_register 5 12 subl $24, %esp 13 movl 8(�p), �x 14 cmpl 12(�p), �x 15 jl .L2 16 movl $13, 4(%esp) 17 movl $.LC0, (%esp) 18 call myprint 19 jmp .L3 20 .L2: 21 movl $13, 4(%esp) 22 movl $.LC1, (%esp) 23 call myprint
movl 8(�p), �x
cmpl 12(�p), �x
jl .L2
movl $13, 4(%esp)
movl $.LC0, (%esp)
上面只取了我們感興趣的地方：ebp指向的是剛進入choose函數的堆棧棧頂指針，此時只想的是剛入棧的ebp的值，ebp+4指向的函數調用入棧的ip地址（這裏應該是段內調用，具體原因不太清楚，因爲兩個文件之間調用函數屬於段內還是段外，我真的不清楚，如果你知道，可以告訴我），ebp+8指向的是調用者壓棧的第二個參數，也是從左邊數第一個參數，ebp+12 是調用者壓棧的第一個參數，也就是從左邊數第二個參數。這樣我們知道了c語言的參數傳遞機制，就能編寫相應的彙編程序調用C語言了，而C 語言調用匯編函數則以此類推，先將第二個參數壓棧，再將第一個參數壓棧。不再贅述。
（
例： void fun(int a, int b) 函數在調用fun時首先將參數b 壓棧，然後將參數 a壓棧，這樣fun 函數在取參數的時候就能先取a了，然後再取b，因爲堆棧是先入後出。如果這樣你還不明白，建議你看一下趙迥老師的linux 0.11內核完全剖析的第三章。
）
(
注：rax:64位，eax：32位 ax：16位
movl： 移動32位，movq：移動64位，movd：移動16位，movb：移動8位
其他帶標誌的指令類似。
)
1 gcc -S -o bar.s -c bar.c (64位的操作系統默認) 2 3 4 5 choose: 6 .LFB0: 7 .cfi_startproc 8 pushq %rbp 9 .cfi_def_cfa_offset 16 10 .cfi_offset 6, -16 11 movq %rsp, %rbp 12 .cfi_def_cfa_register 6 13 subq $16, %rsp 14 movl �i, -4(%rbp) 15 movl %esi, -8(%rbp) 16 movl -4(%rbp), �x 17 cmpl -8(%rbp), �x 18 jl .L2 19 movl $13, %esi 20 movl $.LC0, �i 21 call myprint 22 jmp .L3 23 .L2: 24 movl $13, %esi 25 movl $.LC1, �i 26 call myprint
movl �i, -4(%rbp)
movl %esi, -8(%rbp)
movl -4(%rbp), �x
cmpl -8(%rbp), �x
jl .L2
movl $13, %esi
movl $.LC0, �i
注意64位下的參數傳遞有了改變，而且寄存器也有了改變，不過我們既然使用了nasm彙編，對於64位寄存器的改變暫時不必操心，只需要先關心參數傳遞的格式。
可以看出參數傳遞不是用壓棧的方式傳遞了，而是使用的寄存器來傳遞給被調用者，再由被調用者將其壓棧使用。上述代碼顯示先將第一個參數給edi，然後由被調用者壓入-4（%rbp），然後再將第二個參數給esi，由被調用者要入-8（%rbp），這一點倒是和32位下參數的入棧方式一致。
至於用寄存器傳遞函數參數取代用堆棧傳遞函數參數的原因，個人感覺是函數的調用者不用再操心入棧和釋放棧了，完全由被調用者操心，至少我在函數的調用者裏面經常是記得給函數參數入棧，但是函數調用完成後卻忘記了把棧恢復。
這樣我們就能根據上述規則來修改我們的foo.s,使其能夠與64位的gcc產生的目標代碼鏈接在一起。
至於用寄存器傳遞函數參數的規則見以下參考資料：
==========================================
版權爲 win_hate 所有, 轉載請保留作者名字我這段時間要把以前的一個 x86_32 的 linux 程序移植到 x86_64(AMD) 的 linux 環境裏. 由於寫的是數學算 法, 64 與 32 位有很大不同, 代碼實際上要重寫. 看了點資料後, 覺得 AMD64 的擴展於以前 16 到 32 位的擴展很類 似, e**, 擴展爲 r**, 此外還多了8個通用寄存器 r8~r15.指令格式與32位的極爲相似. 我覺得比較容易, 所以沒再仔細看, 就開 始動手寫了.我的程序由若干個彙編模塊於與若干個c模塊構成, 很多c模塊要調用匯編模塊. 作爲試驗, 我先寫了個簡單的彙編函數, 然後用c來調用. 結果 算出來的值始終是錯誤的. 這令我很惱火, 因爲函數很簡單, 沒有多少出錯的餘地. 後來我把程序反匯編出來, 錯誤馬上浮現出來了, 函數的參數居然 是通過寄存器來傳遞的. 我憑以前的經驗, 從堆棧裏取參數, 算出的結果當然不對了. 我以前不是沒碰到過用寄存器傳遞參數的情況, 但所在的環境都不 是 pc. 在 x86_32/linux 中, 即使用 -O3 優化選項, gcc 仍通過棧來傳遞參數的.所以我們現在知道, 在 x86_64/linux/gcc3.2 中, 即使不打開優化選項, 函數的參數也會通過寄存器來傳遞, 這肯定是闊了的表現(通用寄存器多了).我試驗了多個參數的情況，發現一般規則爲， 當參數少於7個時， 參數從左到右放入寄存器: rdi, rsi, rdx, rcx, r8, r9。當參數爲 7 個以上時， 前 6 個與前面一樣， 但後面的依次從 "右向左" 放入棧中。例如：CODE
(1) 參數個數少於7個:
f (a, b, c, d, e, f);
a->%rdi, b->%rsi, c->%rdx, d->%rcx, e->%r8, f->%r9
g (a, b)
a->%rdi, b->%rsi
有趣的是, 實際上將參數放入寄存器的語句是從右到左處理參數表的, 這點與32位的時候一致.
CODE
2) 參數個數大於 7 個的時候
H(a, b, c, d, e, f, g);
a->%rdi, b->%rsi, c->%rdx, d->%rcx, e->%rax
g->8(%esp)
f->(%esp)
call H
易失寄存器：
%rax, %rcx, %rdx, %rsi, %rdi, %r8, %r9 爲易失寄存器， 被調用者不必恢復它們的值。
顯然，這裏出現的寄存器大多用於參數傳遞了， 值被改掉也無妨。而 %rax, %rdx 常用於
數值計算， %rcx 常用於循環計數，它們的值是經常改變的。其它的寄存器爲非易失的，也
就是 rbp, rbx, rsp, r10~r15 的值如果在彙編模塊中被改變了，在退出該模塊時，必須將
其恢復。
教訓:
用匯編寫模塊, 然後與 c 整合, 一定要搞清楚編譯器的行爲, 特別是參數傳遞的方式. 此外, 我現在比較擔心的一點是, 將來如果要把程序移植
到 WIN/VC 環境怎麼辦? 以前我用cygwin的gcc來處理彙編模塊, 用vc來處理c模塊, 只需要很少改動. 現在的問題是, 如果VC用
不同的參數傳遞方式, 那我不就麻煩了?
補充:
前面的參數 a, b, c, d 等, 都是整數, 長整數, 或指針, 也就是說, 能放到寄存器裏頭的. 如果你要傳遞一個很大的結構, 我估計編譯器也只能通過棧來傳遞了.
環境爲 AMD Athlon64, Mandrak linux 9.2, GCC3.3.1
參考地址：http://hi.baidu.com/bluebanboom/blog/item/381959af65ff36fbfaed5068.html