99%開發(fā)者從未聽說(shuō)過的堆棧模型
朋友： 你知道如何設(shè)置棧最安全么？你知道如何不寫一行匯編代碼就能設(shè)置棧的大小么？你知道如何在鏈接腳本中使用宏和頭文件么？你知道如何在代碼中隨時(shí)隨地檢查棧的最大使用情況么？ 本文從理論到實(shí)踐，從知其然到知其所以然，一杯奶茶的功夫就給你講得明明白白。
在中文嵌入式環(huán)境中，時(shí)不時(shí)的總能看到不少朋友”堆”“?！吧瞪捣植磺宄?，我很早之前在文章《漫談C變量——夏蟲不可語(yǔ)冰》介紹過二者的區(qū)別，這里就不再深入展開，總之：
棧（Stack）“是我們用來(lái)分配局部變量、實(shí)現(xiàn)函數(shù)調(diào)用和在異常響應(yīng)時(shí)保存被打斷代碼上下文的地方——具體細(xì)節(jié)不重要，在本文的討論中，我們只需要記住以下信息：
- Cortex-M系統(tǒng)棧的生長(zhǎng)方向是自上而下的，也就是隨著更多內(nèi)容被壓入（PUSH）棧中，棧頂指針的地址值是越來(lái)越小的——也就是從地址值較大的位置向地址值較小的位置移動(dòng)。
- Cortex-M的棧頂指針指向的是“棧頂部的空位”。
- 從最大兼容性角度考慮，Cortex-M架構(gòu)下棧存儲(chǔ)空間必須對(duì)齊到8字節(jié)。
- 堆本身只是一個(gè)內(nèi)存管理的算法，它所要管理的RAM空間需要用戶通過某種手段將指定大小的RAM空間交到Heap算法手里。
- 與棧不同，堆的生長(zhǎng)方向其實(shí)完全由具體的管理算法決定，而堆的算法數(shù)量雖然不能說(shuō)是燦若星辰，至少一雙手肯定數(shù)不過來(lái)——但一般來(lái)說(shuō)我們可以大體認(rèn)為堆的生長(zhǎng)方向是“自下而上的”——也就是從地址值較小的位置延伸到地址值較大的位置。
- 堆的對(duì)齊要求一般是4字節(jié)起步，8字節(jié)更好，情況不明的直接就32個(gè)字節(jié)吧。
【常見的堆棧模型】
從單純從我不負(fù)責(zé)任的經(jīng)驗(yàn)來(lái)看，由很多GCC領(lǐng)銜使用的“對(duì)向生長(zhǎng)”模型可能是嵌入式領(lǐng)域最常見的”大聰明模型“，沒有之一。如下圖所示：
- 該模型棧和堆共用同一塊連續(xù)的地址區(qū)間
- 配置時(shí)不需要操心具體棧有多大、堆有多大
- 配置方法簡(jiǎn)單：只需要指定這一整塊”堆?！皡^(qū)域的起始地址，以及這一整塊堆棧區(qū)域的大小
- 堆和棧的最大可用大小是此消彼長(zhǎng)的，理論上可以在某種最優(yōu)的情況下達(dá)到動(dòng)態(tài)的”此消彼長(zhǎng)“，可以獲得理想狀下最大的空間復(fù)用效率。
- 堆和棧的最大可用大小是此消彼長(zhǎng)的，在真實(shí)場(chǎng)景中，由于”你長(zhǎng)我也長(zhǎng)誰(shuí)怕誰(shuí)”的情況居多，發(fā)生隨機(jī)性的“雙向奔赴”從而進(jìn)行“負(fù)距離”的互動(dòng)可能性從理論上就不可避免，因而是系統(tǒng)穩(wěn)定性的“一生之?dāng)场?/span>。
- 實(shí)驗(yàn)室里7x24小時(shí)完美通過，一去客戶那里就隨機(jī)性宕機(jī)的“挖坑之王”。
為了提高系統(tǒng)穩(wěn)定性，人們簡(jiǎn)單地將“堆”和“?！辈痖_來(lái)單獨(dú)配置，就獲得了常見的“兩段式堆棧模型”：
【最安全的“兩面包夾芝士”模型】
將“棧（Stack）”和"堆(Heap)"獨(dú)立配置的“兩段式”模型配合邊界金絲雀，為預(yù)防和檢測(cè)堆棧溢出提供了可能。但對(duì)金絲雀的檢測(cè)總歸有種“事后諸葛亮”的感覺，而且很多時(shí)候，我們是想不起來(lái)去檢查金絲雀的，比如：棧曾經(jīng)一度跨越雷池入侵到了堆空間，但由于此時(shí)堆恰巧分配出去的RAM不多，沒有與棧發(fā)生實(shí)質(zhì)性的重疊，因而整個(gè)系統(tǒng)“安然無(wú)恙”——這只能說(shuō)是運(yùn)氣好，而風(fēng)險(xiǎn)肯定是存在的——正由于系統(tǒng)“安然無(wú)恙”，因此我們?cè)谙到y(tǒng)開發(fā)階段可能不會(huì)想起來(lái)去檢查一下金絲雀（有自動(dòng)檢查機(jī)制的RTOS除外），那么這類溢出就有可能被隱藏。
基于上述原因，有沒有一種方法可以：
- 徹底避免棧/堆入侵對(duì)系統(tǒng)的破壞
- 在棧/堆入侵的瞬間就立即表現(xiàn)出來(lái)——方便我們?cè)谡{(diào)試階段立即發(fā)現(xiàn)
- 該模型屬于“兩段式模型”的變種
- 與過去堆和棧的“相向生長(zhǎng)”不同，該模型采用了“背向生長(zhǎng)”的方式——避免了棧與堆的相互傷害
- 棧被放在了SRAM的起始位置（Cortex-M從架構(gòu)上鼓勵(lì)將SRAM放置在從0x2000-0000開始的地址上），這樣一旦發(fā)生棧溢出，指針就會(huì)指向SRAM存儲(chǔ)器以外的無(wú)效位置——這在大部分芯片上會(huì)觸發(fā)“Bus Fault”，從而產(chǎn)生故障異?！?/span>這就實(shí)現(xiàn)了對(duì)棧溢出的當(dāng)場(chǎng)捕獲，并且不依賴MPU或者“棧底地址限制檢測(cè)（Stack Limit Checking）”之類的架構(gòu)特性。
當(dāng)然有些芯片設(shè)計(jì)者可能會(huì)選擇“隱藏這類錯(cuò)誤”，不僅不會(huì)觸發(fā)異常，而且會(huì)當(dāng)做無(wú)事發(fā)生，具體表現(xiàn)為：對(duì)無(wú)效地址的寫入操作將被無(wú)視，對(duì)無(wú)效地址的讀取操作將會(huì)返回0值。具體可以參考芯片手冊(cè)，或者干脆做個(gè)實(shí)驗(yàn)。
- 堆被放置在了RAM的最后，中間夾著存放靜態(tài)/全局變量的“RW/ZI區(qū)域”，這也是“兩面包夾芝士”模型（或者“三明治”模型）名稱的由來(lái)。這樣的安排也徹底杜絕了棧和堆對(duì)“RW/ZI區(qū)域”發(fā)生入侵的可能。當(dāng)堆溢出時(shí)，與棧類似，對(duì)大部分芯片來(lái)說(shuō)都會(huì)觸發(fā)故障異常，從而在開發(fā)調(diào)試階段第一時(shí)間被我們所捕獲。
- 通過鏈接腳本（比如Arm Compiler的Scatter Script或者gcc、clang的ld）的一些運(yùn)算功能，我們甚至可以做到“將剩下的空間全留給HEAP”，從而簡(jiǎn)化系統(tǒng)的配置。
【Arm官方低調(diào)推薦的”新“方法】
其實(shí)，Arm Compiler 在很久之前就逐步淘汰了“大聰明的單段對(duì)向生長(zhǎng)模型”，而“兩段模型”早已成為主流。比如，我們?cè)趨R編啟動(dòng)文件中經(jīng)?？梢砸姷竭@樣的代碼片段：
這就是“兩段式”模型的證據(jù)。實(shí)際上，在啟動(dòng)代碼的尾部，匯編程序通過：
IMPORT __use_two_region_memory
選擇了對(duì)兩段式模型提供支持的libc庫(kù)：
注意：此步驟只針對(duì)使用匯編啟動(dòng)文件的情況。如果你的啟動(dòng)文件是C，則可跳過該步驟。
在工程管理器中找到你的匯編啟動(dòng)文件，它通常以
startup_<芯片型號(hào)>.s
的形式命名：
繼續(xù)移動(dòng)到匯編文件的尾部，找到如下的代碼：
移動(dòng)到中斷向量表的定義處：
__VectorsDCD__initial_sp
替換為如下內(nèi)容：
IMPORT |Image$$ARM_LIB_STACK$$ZI$$Limit|
__VectorsDCD|Image$$ARM_LIB_STACK$$ZI$$Limit|
即：
此時(shí)，如果你著急編譯，當(dāng)你當(dāng)你開啟了microLib時(shí)，很可能會(huì)看到如下的鏈接錯(cuò)誤：
Error: L6218E: Undefined symbol __initial_sp (referred from entry2.o).
或者你沒有開啟 microLib，則會(huì)看到一個(gè)不同的錯(cuò)誤：
Error: L6915E: Library reports error: The semihosting __user_initial_stackheap cannot reliably set up a usable heap region if scatter loading is in use
這都是正常的，不必驚慌。這類錯(cuò)誤會(huì)在完成后面的步驟后自然消失。步驟二：獲取鏈接腳本（Scatter Script）
打開工程配置窗口“Options for Target”，切換到“Linker”選項(xiàng)卡：
單擊 Edit 按鈕，可以看到腳本的內(nèi)容：
為了避免該問題，應(yīng)該將它從 Out 目錄中移動(dòng)到工程目錄下。具體步驟為，右鍵單擊腳本文件名：
在編輯器中打開我們的腳本文件：
是的，你的猜測(cè)沒錯(cuò)：當(dāng)我們沒有特別說(shuō)明時(shí)，Stack和Heap都以ZI的形式存在于上述空間內(nèi)，其位置任由Linker擺布——這當(dāng)然也帶來(lái)了很多不確定性。
接下來(lái)我們要做的就是按照我們的設(shè)計(jì)——“兩面包夾芝士”來(lái)明確的指定棧和隊(duì)列的大小和位置：
ARM_LIB_STACK 0x20000000 ALIGN 8 EMPTY 0x800 {}
這里：- 起始地址是 0x20000000
- STACK的大小是 0x800
- ALIGN 8 指定對(duì)齊是8個(gè)字節(jié)
- EMPTY是必須要保留的，它用來(lái)說(shuō)明 ARM_LIB_STACK 是一個(gè)大數(shù)組，里面默認(rèn)填充了0。
- 如果你想修改填充的內(nèi)容還可以通過關(guān)鍵字 FILL <填充值> 來(lái)指定填充的32bit數(shù)值，比如：
ARM_LIB_STACK 0x20000000 ALIGN 8 FILL 0xDEADBEEF EMPTY 0x800 {}
它實(shí)現(xiàn)了往0x20000000開始的0x800（2KB）大小的?？臻g中填充0xDEADBEEF的功能：
為了讓ZI/RW緊隨其后——放在STACK的后面，我們需要對(duì) RW_IRAM1 的描述進(jìn)行修改，即從：
RW_IRAM1 0x20000000 0x00020000 {
修改為：
RW_IRAM1+0{
即：
接下來(lái)，我們要用類似的方法緊隨 RW_IRAM1 之后放置名為 ARM_LIB_HEAP 的execution region——用來(lái)指定堆的位置和大小：
ARM_LIB_HEAP +0 ALIGN 8 EMPTY 0x200 {}
可以看到，這里與棧的設(shè)置方式幾乎一樣，而“+0”則同樣告訴linker：請(qǐng)將ARM_LIB_HEAP緊鄰前面的 RW_IRAM1 放置。最終的效果如下：
LR_IROM1 0x00000000 0x00040000 {
ER_IROM1 0x00000000 0x00040000 {
(RESET, +First)
*(InRoot$$Sections)
(+RO)
(+XO)
}
ARM_LIB_STACK 0x20000000 ALIGN 8 EMPTY 0x800 {}
0x20000000 0x00020000 { ; RW data
RW_IRAM1 +0 { ; RW data
(+RW +ZI)
}
ARM_LIB_HEAP+0ALIGN8EMPTY0x200{}
}
還記得我們前面刪除了原本對(duì)RW_IRAM1的尺寸限制（也就是0x0002000）么？這意味著，現(xiàn)階段的腳本文件對(duì)我們實(shí)際使用的RAM空間是沒有任何限制的——換句話說(shuō)，如果超出了芯片實(shí)際的SRAM大小，編譯器也是不會(huì)報(bào)告錯(cuò)誤的。為了重新加入這一限制，我們可以在 ARM_LIB_HEAP的后面加入下面的語(yǔ)句：
ScatterAssert(ImageLimit(ARM_LIB_HEAP) <= 0x20000000 + 0x20000)
這里：- ScatterAssert() 是讓linker對(duì)括號(hào)中的內(nèi)容進(jìn)行檢查
- ImageLimit() 是在編譯時(shí)刻獲得括號(hào)內(nèi)指定execution region的終止地址
- 0x20000000+0x20000是例子中整個(gè)RAM的終止地址（這里假設(shè)RAM從0x20000000開始，大小是0x20000）
- 綜合來(lái)說(shuō)，上述代碼的作用是在linker的鏈接階段計(jì)算HEAP的終止地址，確認(rèn)它是否落在了RAM的有效范圍內(nèi)。
Error:L6388E:ScatterAssertexpression(ImageLimit(ARM_LIB_HEAP)<=?0x20000000?+?0x20000)?failed?on?line?22?:?(0x20001220?<=?0x20020000)
最終效果如下：
對(duì)應(yīng)的“兩面包夾芝士”圖示如下：
【“雖遲但到”的宏和頭文件】
是的，你猜得沒錯(cuò)，我們可以在鏈接腳本中使用編譯預(yù)處理，這意味著：
- 我們可以使用宏
- 我們可以include頭文件
- 我們可以進(jìn)行條件編譯
具體方法并不難，只需要在鏈接腳本的“第一行”，注意一定要是第一行（Number One）——前面不能有任何內(nèi)容，空行或者注釋都不行——放置如下的內(nèi)容：
#define RAM1_SIZE 0x00020000
#define RAM1_BASE 0x20000000
#define RAM1_LIMIT (RAM1_BASE + RAM1_SIZE)
#define STACK_SIZE 0x800
#define HEAP_SIZE 0x200
需要注意的是：
- 在較新版本的MDK中，上述方法“應(yīng)該”同時(shí)支持Arm Compiler 5（armcc）和Arm Compiler 6（armclang）。你可以關(guān)注【裸機(jī)思維】公眾號(hào)后，發(fā)送關(guān)鍵字“MDK”來(lái)獲取最新的MDK。
...
以解決可能出現(xiàn)的編譯錯(cuò)誤。
- 如果你的頭文件并沒有“直接”放置在工程目錄下，而是存在一個(gè)相對(duì)路徑，則可以通過在上述命令行中追加 -I <路徑> 的形式來(lái)告知編譯器去哪里搜索我們的頭文件。比如：
或者
則是告訴編譯器從相對(duì)路徑 "../../cfg" 下去搜索頭文件。
-
當(dāng)你通過修改頭文件的方式來(lái)更新scatter script的內(nèi)容后，第一次編譯，請(qǐng)務(wù)必一定要以“Rebuild All”的形式進(jìn)行，否則你的修改不會(huì)生效。
別說(shuō)我沒提醒過你哦！
【如何把剩余的空間都留給堆】
很多時(shí)候，把剩余空間都留給堆是一個(gè)不錯(cuò)的想法，這樣“兩面包夾芝士”模型就獲得了和“單段相向生長(zhǎng)”模型一樣的優(yōu)勢(shì)——配置簡(jiǎn)單。由于我們已經(jīng)有了宏的幫助，借助 ImageLimit() 我們可以將 HEAP_SIZE 的宏定義修改為：
它的意思是：用RAM1的終止地址減去 RW_IRAM1的終止地址，獲得中間的差額，其圖示如下：
看似完美，有的小伙伴一編譯就會(huì)報(bào)告如下的錯(cuò)誤：
即：
Error: L6388E: ScatterAssert expression (ImageLimit(ARM_LIB_HEAP) <= (0x20000000 + 0x20000)) failed on line 29 : (0x20020004 <= 0x20020000)
奇怪，我們的計(jì)算公式應(yīng)該沒錯(cuò)啊——Heap的尺寸應(yīng)該就是使用整個(gè) RAM的終止地址減去 RW_IRAM1 的終止地址啊，為什么提示差4個(gè)字節(jié)呢？
聰明的小伙伴一定已經(jīng)注意到了，我們?cè)?ARM_LIB_HEAP 的定義中，指定了其首地址的對(duì)齊為8字節(jié)：
ARM_LIB_HEAP +0 ALIGN 8 EMPTY HEAP_SIZE {}
而 RW_IRAM1 的尺寸不一定是8的整倍數(shù)，當(dāng)它只是“4的整倍數(shù)”而不滿足“8的整倍數(shù)”這一條件時(shí)，ImageLimit(RW_IRAM1)的后面與 ARM_LIB_HEAP的起始地址之間就會(huì)產(chǎn)生一個(gè)4字節(jié)的氣泡：
要解決這一問題也很簡(jiǎn)單，我們可以使用 scatter script 腳本為我們提供的一個(gè)專門來(lái)進(jìn)行地址對(duì)齊的函數(shù)：
AlignExpr(<地址數(shù)值>,<對(duì)齊要求>)
比如：
AlignExpr(ImageLimit(RW_IRAM1), 8)
就表示對(duì) RW_IRAM1 的終止地址進(jìn)行 8 字節(jié)對(duì)齊。借助它的幫助，我們可以修改腳本如下：
(RAM1_LIMIT-AlignExpr(ImageLimit(RW_IRAM1),8))
即：
再編譯時(shí)，已然沒有問題。
【如何隨時(shí)隨地的了解棧的最大使用情況】
水印法是實(shí)現(xiàn)“最大棧用量統(tǒng)計(jì)”的最有效方式。其原理也不復(fù)雜：
- 先用指定的水印常數(shù)（比如 0xDEADBEEF）將整個(gè)棧填滿；
- 從棧空間的最初頂部（棧存儲(chǔ)空間的終止地址）向下開始搜索之前填充的水印常數(shù)——一旦碰到水印，就將當(dāng)前已經(jīng)經(jīng)歷過的RAM總量作為棧的最大深度（最大用量）；
ARM_LIB_STACK0x20000000ALIGN8FILL0xDEADBEEFEMPTYSTACK_SIZE
{
}
然后借助下面的代碼完成統(tǒng)計(jì)工作：
uint32_t calculate_stack_usage_topdown(void)
{
extern uint32_t Image$$ARM_LIB_STACK$$Limit[];
extern uint32_t Image$$ARM_LIB_STACK$$Length;
uint32_t *pwStack = Image$$ARM_LIB_STACK$$Limit;
uint32_t wStackSize = (uintptr_t)&Image$$ARM_LIB_STACK$$Length / 4;
uint32_t wStackUsed = 0;
do {
if (*--pwStack == 0xDEADBEEF) {
break;
}
wStackUsed++;
} while(--wStackSize);
printf("
Stack Usage: [%d/%d] %2.2f%%
",
wStackUsed * 4,
(uintptr_t)&Image$$ARM_LIB_STACK$$Length,
( (float)wStackUsed * 400.0f
/ (float)(uintptr_t)&Image$$ARM_LIB_STACK$$Length));
return wStackUsed * 4;
}
這里有幾點(diǎn)需要說(shuō)明一下：
-
armlink 為我們提供了通用的語(yǔ)法來(lái)獲取 execution region 的起始地址、大小和終止地址：
extern uint32_t Image$$$$Base[];
externuint32_tImage$$$$Length;
extern uint32_t Image$$$$Limit[];
這里，Base和Limit被定義成了不定長(zhǎng)數(shù)組的形式，因此我們可以直接把它們當(dāng)做常量指針來(lái)使用——獲取所需的地址。Length被定義成了一個(gè)普通的uint32_t型的變量，按照官方文檔的要求，雖然很反直覺，但如果要獲取它的值——也就是對(duì)應(yīng)execution region的大小，必須要對(duì)其進(jìn)行&操作，并隨后強(qiáng)制轉(zhuǎn)化為整形數(shù)值。這么說(shuō)也許有點(diǎn)抽象，不妨對(duì)照前面的代碼來(lái)看：
#include
這里，我們通過 Image$ARM_LIB_STACK$$Limit[] 將棧的終止地址賦值給了(uint32_t *)型的指針 pwStack。以表達(dá)式 (uintptr_t)&Image$$ARM_LIB_STACK$$Length 獲取了 ARM_LIB_STACK 的實(shí)際大小。
-
普通情況下，在變量名中使用 “$” 會(huì)在Arm Compiler 6引發(fā)警告：
warning:'$'inidentifier[-Wdollar-in-identifier-extension]
為了讓編譯器閉嘴，我們臨時(shí)對(duì)函數(shù) calculate_stack_usage_topdown() 在編譯時(shí)刻做了屏蔽warning的操作：
uint32_t calculate_stack_usage_topdown(void)
{
...
}
而 -Wdouble-promotion 則是由printf中的百分比運(yùn)算引起的，一并屏蔽即可。
在任意時(shí)刻，當(dāng)我們想要知道當(dāng)前系統(tǒng)的最大棧用量時(shí)，可以直接調(diào)用函數(shù) calculate_stack_usage_topdown()，比如：
int main(void)
{
...
calculate_stack_usage_topdown();
...
}
一個(gè)可能的執(zhí)行結(jié)果如下：
自上而下統(tǒng)計(jì)棧用量的方法優(yōu)點(diǎn)是：當(dāng)棧空間很大而實(shí)際棧用量較小時(shí)，可以較快的完成統(tǒng)計(jì)；缺點(diǎn)是：如果恰好棧里因?yàn)槿魏卧颍ū热缬脩舳x了一個(gè)局部變量，然后恰好給他賦予了我們的水印常數(shù)），就會(huì)造成統(tǒng)計(jì)錯(cuò)誤——沒能實(shí)際獲得最大深度。
針對(duì)這一問題，我們可以修改搜索策略，從占空間的起始地址（也就是基地址）處向上搜索“非水印常數(shù)”——一旦碰到，就可以用已知的?？臻g尺寸減去已經(jīng)經(jīng)歷過的RAM總量作為棧的最大深度（最大用量）。
該方法的優(yōu)點(diǎn)是：不容易發(fā)生誤判；缺點(diǎn)是：當(dāng)?？臻g很大而實(shí)際棧用量較小時(shí)往往較為耗時(shí)。對(duì)應(yīng)的代碼如下：
uint32_t calculate_stack_usage_bottomup(void)
{
extern uint32_t Image$$ARM_LIB_STACK$$Base[];
extern uint32_t Image$$ARM_LIB_STACK$$Length;
uint32_t *pwStack = Image$$ARM_LIB_STACK$$Base;
uint32_t wStackSize = (uintptr_t)&Image$$ARM_LIB_STACK$$Length;
uint32_t wStackUsed = wStackSize / 4;
do {
if (*pwStack++ != 0xDEADBEEF) {
break;
}
} while(--wStackUsed);
printf("
Stack Usage: [%d/%d] %2.2f%%
",
wStackUsed * 4,
wStackSize,
((float)wStackUsed*400.0f/(float)wStackSize));
return wStackUsed * 4;
}
【后記】
在這篇文章中，我們介紹了棧和堆在存儲(chǔ)器中的常見排布模型，比較了它們的優(yōu)劣，并提出了一種被稱為“兩面包夾芝士”的兩段式模型。該模型：
- 可以有效避免堆棧溢出破壞常規(guī)變量
- 溢出發(fā)生時(shí)可以在大部分芯片中第一時(shí)間觸發(fā)異?！晃覀儾蹲降?/span>
后面，我們以MDK為例介紹了如何在Arm Compiler環(huán)境下應(yīng)用這一模型，并引入了使用宏對(duì)其進(jìn)行進(jìn)一步拓展的方法。
值得說(shuō)明的是，這一方法對(duì)Arm Compiler 5（armcc）和Arm Compiler 6（armclang）同樣適用。支持MicroLib和非MicroLib的情況。無(wú)論啟動(dòng)文件是否為匯編，都可以正常工作。
實(shí)際上，使用鏈接腳本而非匯編啟動(dòng)文件來(lái)對(duì)兩段式堆棧模型進(jìn)行配置是Arm公司一直以來(lái)所提倡的。隨著Arm Compiler 6的逐步普及，更多的芯片公司正在追隨Arm的腳步將原本的匯編啟動(dòng)文件替換為 CMSIS 目錄下所提倡的純C語(yǔ)言啟動(dòng)文件。
作為【反復(fù)橫跳】系列的一部分，我希望通過這篇文章能幫助大家掃清從Arm Compiler 5向Arm Compiler 6過渡圖中與棧相關(guān)的障礙。希望對(duì)你有所幫助。
審核編輯 ：李倩
-
嵌入式
+關(guān)注
關(guān)注
5194文章
20289瀏覽量
331907 -
堆棧
+關(guān)注
關(guān)注
0文章
183瀏覽量
20471 -
變量
+關(guān)注
關(guān)注
0文章
615瀏覽量
29446
原文標(biāo)題：99%開發(fā)者從未聽說(shuō)過的堆棧模型
文章出處：【微信號(hào)：pzh_mcu，微信公眾號(hào)：痞子衡嵌入式】歡迎添加關(guān)注！文章轉(zhuǎn)載請(qǐng)注明出處。
發(fā)布評(píng)論請(qǐng)先 登錄
2025華為開發(fā)者大賽暨開發(fā)者年度會(huì)議成功舉辦
2025開源鴻蒙開發(fā)者激勵(lì)計(jì)劃正式啟動(dòng)
元服務(wù)發(fā)布配置開發(fā)者服務(wù)信息
2025開放原子開發(fā)者大會(huì)11月啟幕
NVIDIA DRIVE AGX Thor開發(fā)者套件重磅發(fā)布
曙光網(wǎng)絡(luò)SugonRI開發(fā)者社區(qū)正式上線
迅龍軟件參加昇騰 AI?開發(fā)者創(chuàng)享日?廣東站，為開發(fā)者打造沉浸式實(shí)操體驗(yàn)
【瑞芯微開發(fā)者大會(huì)】Firefly 與你共同見證 AIoT 模型創(chuàng)新
矽速科技正式入駐 RuyiSDK 開發(fā)者社區(qū)，共建 RISC-V 開發(fā)者生態(tài)！
HDC 2025開發(fā)者主題演講精彩回顧
華為正式啟動(dòng)HarmonyOS 6開發(fā)者Beta
Create2025百度AI開發(fā)者大會(huì)精彩回顧
Arm亮相2025年游戲開發(fā)者大會(huì)
涂鴉智能與火山引擎達(dá)成重磅合作，億元補(bǔ)貼全力構(gòu)建AIoT開發(fā)者生態(tài)
工商網(wǎng)監(jiān)
評(píng)論