摘要：linux程式運作的狀态以及如何推導調用棧。
1、背景知識
1、ARM64寄存器介紹：
2、STP指令詳解（ARMV8手冊）：
我們先看一下指令格式（64bit），以及指令對于寄存機執行結果的影響
類型1、STP <Xt1>, <Xt2>, [<Xn|SP>], #<imm>
将Xt1和Xt2存入Xn|SP對應的位址記憶體中，然後，将Xn|SP的位址變更為Xn|SP + imm偏移量的新位址
類型2、STP <Xt1>, <Xt2>, [<Xn|SP>, #<imm>]!
将Xt1和Xt2存入Xn|SP的位址自加imm對應的位址記憶體中，然後，将Xn|SP的位址變更為Xn|SP + imm的offset偏移量後的新位址
類型3、STP <Xt1>, <Xt2>, [<Xn|SP>{, #<imm>}]
将Xt1和Xt2存入Xn|SP的位址自加imm對應的位址記憶體中
手冊中有三種操作碼，我們隻讨論程式中涉及的後兩種
Pseudocode如下：
Shared decode for all encodings
integer n = UInt(Rn);
integer t = UInt(Rt);
integer t2 = UInt(Rt2);
if L:opc<0> == '01' || opc == '11' then UNDEFINED;
integer scale = 2 + UInt(opc<1>);
integer datasize = 8 << scale;
bits(64) offset = LSL(SignExtend(imm7, 64), scale);
boolean tag_checked = wback || n != 31;
Operation for all encodings
bits(64) address;
bits(datasize) data1;
bits(datasize) data2;
constant integer dbytes = datasize DIV 8;
boolean rt_unknown = FALSE;
if HaveMTEExt() then
SetNotTagCheckedInstruction(!tag_checked);
if wback && (t == n || t2 == n) && n != 31 then
Constraint c = ConstrainUnpredictable();
assert c IN {Constraint_NONE, Constraint_UNKNOWN, Constraint_UNDEF, Constraint_NOP};
case c of
when Constraint_NONE rt_unknown = FALSE; // value stored is pre-writeback
when Constraint_UNKNOWN rt_unknown = TRUE; // value stored is UNKNOWN
when Constraint_UNDEF UNDEFINED;
when Constraint_NOP EndOfInstruction();
if n == 31 then
CheckSPAlignment();
address = SP[];
else
address = X[n];
if !postindex then
address = address + offset;
if rt_unknown && t == n then
data1 = bits(datasize) UNKNOWN;
else
data1 = X[t];
if rt_unknown && t2 == n then
data2 = bits(datasize) UNKNOWN;
else
data2 = X[t2];
Mem[address, dbytes, AccType_NORMAL] = data1;
Mem[address+dbytes, dbytes, AccType_NORMAL] = data2;
if wback then
if postindex then
address = address + offset;
if n == 31 then
SP[] = address;
else
X[n] = address; 紅色部分對應推棧的關鍵邏輯，其他彙編指令含義可自行參考armv8手冊或者度娘。
2、一個例子
熟悉了上面的部分，接下來我們看一個執行個體：
C代碼如下：
相關的幾個函數反彙編如下（和推棧相關的一般隻有入口兩條指令）：
main\f3\f4\strlen 我們通過gdb運作後，可以看到strlen地方會觸發SEGFAULT，引發程序挂掉
上述通過代碼編譯後，沒有strip，是以elf檔案是帶着符号的
檢視運作狀态（info register）：關注$29、$30、SP、PC四個寄存器
一個核心的思想：CPU執行的是指令而不是C代碼，函數調用和傳回實際是線上程棧上面的壓棧和彈棧的過程
接下來我們來看上面的調用關系在目前這個任務棧是如何玩的：
函數調用在棧中的關系（call function壓棧，位址遞減；return彈棧，位址遞增）：
以下是推棧的過程（劃重點）
再回頭來看之前的彙編：
main\f3\f4\strlen 從目前的sp開始，frame 0是strlen，這塊沒有開棧，是以上一級的調用函數仍然是x30，是以推導：frame1調用為f3
函數f3的起始入口彙編：
(gdb) x/2i f3
0x400600 <f3>: stp x29, x30, [sp,#-48]!
0x400604 <f3+4>: mov x29, sp 可以看到，f3函數開辟的棧空間為48位元組，是以，倒推frame2的棧頂為目前的sp + 48位元組：0xfffffffff2c0
(gdb) x/gx 0xfffffffff2c0+8
0xfffffffff2c8: 0x000000000040065c
(gdb) x/i 0x000000000040065c
0x40065c <f4+36>: mov w0, #0x0 // #0
frame2的函數為sp+8：0x000000000040065c -> <f4+36> 繼續從sp = 0xfffffffff2c0倒推frame1的函數
函數f4的起始入口彙編為:
(gdb) x/2i f4
0x400638 <f4>: stp x29, x30, [sp,#-48]!
0x40063c <f4+4>: mov x29, sp 可以看到，f4函數開辟的棧空間也是為48位元組，是以，倒推frame3的棧頂為目前的0xfffffffff2c0 + 48位元組：0xfffffffff2f0
frame2的函數為0xfffffffff2c0 + 8：0x000000000040065c -> <f4+36>
(gdb) x/gx 0xfffffffff2f0+8
0xfffffffff2f8: 0x0000000000400684
(gdb) x/i 0x0000000000400684
0x400684 <main+28>: mov w0, #0x0 // #0 是以frame3的函數為main函數，main函數對應的棧頂為0xfffffffff320
至此推導結束（有興趣的同學可以繼續推導，可以看到libc如何拉起main的過程）
總結：
推棧的關鍵：
- 目前的現場
- 熟悉cpu體系架構的開棧的方式
3、實戰講解
現場有如下的core：可以看到，所有的符号找不到，加載了符号表依然不好使，解析不出來實際的調用棧
(gdb) bt
#0 0x0000ffffaeb067bc in ?? () from /lib64/libc.so.6
#1 0x0000aaaad15cf000 in ?? ()
Backtrace stopped: previous frame inner to this frame (corrupt stack?) 先看info register，關注x29、x30、sp、pc四個寄存器的值
推導任務棧：
先将sp内容導出：
下圖實際已先将結果标出，我們下面來較長的描述如何推導
pc代表目前執行的函數指令，如果目前指令未開棧，一般情況x30代表上一級的frame調用目前函數的下一條指令，檢視彙編，可以反解為如下函數
(gdb) x/i 0xaaaacd3de4fc
0xaaaacd3de4fc <PGXCNodeConnStr(char const*, int, char const*, char const*, char const*, char const*, int, char const*)+108>: mov x27, x0 找到棧頂函數後，檢視該函數的棧操作：
(gdb) x/6i PGXCNodeConnStr
0xaaaacd3de490 <PGXCNodeConnStr(char const*, int, char const*, char const*, char const*, char const*, int, char const*)>: sub sp, sp, #0xd0
0xaaaacd3de494 <PGXCNodeConnStr(char const*, int, char const*, char const*, char const*, char const*, int, char const*)+4>: stp x29, x30, [sp,#80]
0xaaaacd3de498 <PGXCNodeConnStr(char const*, int, char const*, char const*, char const*, char const*, int, char const*)+8>: add x29, sp, #0x50 可以看到，上一級的frame存在了目前的sp + 0xd0 - 0x80也就是0xfffec4cebd40 + 0xd0 - 0x80 = 0xfffec4cebd90的地方，而棧底在0xfffec4cebd40+ 0xd0 = 0xfffec4cebe10的地方
是以就找到了下一級的frame對應的棧頂和上一級的LR傳回指令，反解，可以得到函數build_node_conn_str
(gdb) x/i 0x0000aaaacd414e08
0xaaaacd414e08 <build_node_conn_str(Oid, DatabasePool*)+224>: mov x21, x0 繼續重複上述推導，可以看到這個函數build_node_conn_str開了176位元組的棧，
(gdb) x/4i build_node_conn_str
0xaaaacd414d28 <build_node_conn_str(Oid, DatabasePool*)>: stp x29, x30, [sp,#-176]!
0xaaaacd414d2c <build_node_conn_str(Oid, DatabasePool*)+4>: mov x29, sp 是以繼續用0xfffec4cebe10 + 176 = 0xfffec4cebec0
檢視調用者0xfffec4cebe10+8為reload_database_pools
繼續看reload_database_pools
(gdb) x/8i reload_database_pools
0xaaaacd4225e8 <reload_database_pools(PoolAgent*)>: sub sp, sp, #0x1c0
0xaaaacd4225ec <reload_database_pools(PoolAgent*)+4>: adrp x5, 0xaaaad15cf000
0xaaaacd4225f0 <reload_database_pools(PoolAgent*)+8>: adrp x3, 0xaaaacf0ed000
0xaaaacd4225f4 <reload_database_pools(PoolAgent*)+12>: adrp x4, 0xaaaaceeed000 <_ZN4llvm18ConvertUTF8toUTF16EPPKhS1_PPtS3_NS_15ConversionFlagsE>
0xaaaacd4225f8 <reload_database_pools(PoolAgent*)+16>: add x3, x3, #0x9e0
0xaaaacd4225fc <reload_database_pools(PoolAgent*)+20>: adrp x1, 0xaaaacf0ee000 <_ZZ25PoolManagerGetConnectionsP4ListS0_E8__func__+24>
0xaaaacd422600 <reload_database_pools(PoolAgent*)+24>: stp x29, x30, [sp,#-96]! 實際開棧0x220位元組，是以這一層frame的棧底為0xfffec4cebec0 + 0x220 = 0xfffec4cec0e0
是以得到基本的調用關系的結構如下
以上基本可以夠用來分析問題了，是以不需要再繼續推導
TIPS：arm架構下一般調用都會使用這種指令，
stp x29, x30, [sp,#immediate]! 有歎号或者無歎号
是以在每一層的frame都儲存了上一層frame的棧頂位址和LR指令，通過準确找到底層的frame 0棧頂後，就可以快速推導出所有的調用關系（紅色虛線圈出來的部分），函數的反解依賴符号表，隻要原始的elf檔案的symbol段沒有strip掉，是都可以找到對應的函數符号（通過readelf -S檢視即可）
找到Frame後，每一層frame裡面的内容，結合彙編基本就可以用來推導過程變量了。
本文分享自華為雲社群《代碼 or 指令，淺析ARM架構下的函數的調用過程》，原文作者：K______。
點選關注，第一時間了解華為雲新鮮技術~