---

朋友： 你知道如何設(shè)置棧最安全么？你知道如何不寫一行匯編代碼就能設(shè)置棧的大小么？你知道如何在鏈接腳本中使用宏和頭文件么？你知道如何在代碼中隨時(shí)隨地檢查棧的最大使用情況么？ 本文從理論到實(shí)踐，從知其然到知其所以然，一杯奶茶的功夫就給你講得明明白白。

在中文嵌入式環(huán)境中，時(shí)不時(shí)的總能看到不少朋友”堆”“棧“傻傻分不清楚，我很早之前在文章《漫談C變量——夏蟲不可語(yǔ)冰》介紹過二者的區(qū)別，這里就不再深入展開，總之：
棧（Stack）“是我們用來分配局部變量、實(shí)現(xiàn)函數(shù)調(diào)用和在異常響應(yīng)時(shí)保存被打斷代碼上下文的地方——具體細(xì)節(jié)不重要，在本文的討論中，我們只需要記住以下信息：

• Cortex-M系統(tǒng)棧的生長(zhǎng)方向是自上而下的，也就是隨著更多內(nèi)容被壓入（PUSH）棧中，棧頂指針的地址值是越來越小的——也就是從地址值較大的位置向地址值較小的位置移動(dòng)。
• Cortex-M的棧頂指針指向的是“棧頂部的空位”。
• 從最大兼容性角度考慮，Cortex-M架構(gòu)下棧存儲(chǔ)空間必須對(duì)齊到8字節(jié)。

“堆（Heap）”是我們使用 malloc 申請(qǐng)動(dòng)態(tài)存儲(chǔ)空間時(shí)所必須用到的一種數(shù)據(jù)結(jié)構(gòu)——通常由C語(yǔ)言的系統(tǒng)庫(kù)提供。

• 堆本身只是一個(gè)內(nèi)存管理的算法，它所要管理的RAM空間需要用戶通過某種手段將指定大小的RAM空間交到Heap算法手里。
• 與棧不同，堆的生長(zhǎng)方向其實(shí)完全由具體的管理算法決定，而堆的算法數(shù)量雖然不能說是燦若星辰，至少一雙手肯定數(shù)不過來——但一般來說我們可以大體認(rèn)為堆的生長(zhǎng)方向是“自下而上的”——也就是從地址值較小的位置延伸到地址值較大的位置。
• 堆的對(duì)齊要求一般是4字節(jié)起步，8字節(jié)更好，情況不明的直接就32個(gè)字節(jié)吧。

【常見的堆棧模型】

---

從單純從我不負(fù)責(zé)任的經(jīng)驗(yàn)來看，由很多GCC領(lǐng)銜使用的“對(duì)向生長(zhǎng)”模型可能是嵌入式領(lǐng)域最常見的”大聰明模型“，沒有之一。如下圖所示：

先說優(yōu)點(diǎn)吧：

• 該模型棧和堆共用同一塊連續(xù)的地址區(qū)間
• 配置時(shí)不需要操心具體棧有多大、堆有多大
• 配置方法簡(jiǎn)單：只需要指定這一整塊”堆棧“區(qū)域的起始地址，以及這一整塊堆棧區(qū)域的大小
• 堆和棧的最大可用大小是此消彼長(zhǎng)的，理論上可以在某種最優(yōu)的情況下達(dá)到動(dòng)態(tài)的”此消彼長(zhǎng)“，可以獲得理想狀下最大的空間復(fù)用效率。

缺點(diǎn)也很明顯：

• 堆和棧的最大可用大小是此消彼長(zhǎng)的，在真實(shí)場(chǎng)景中，由于”你長(zhǎng)我也長(zhǎng)誰怕誰”的情況居多，發(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)單地將“堆”和“棧”拆開來單獨(dú)配置，就獲得了常見的“兩段式堆棧模型”：

可以看到，相較之前的模型，雖然仍然是“對(duì)向生長(zhǎng)”，但由于棧和堆有了自己固定空間，因此可以方便地根據(jù)實(shí)際用量調(diào)整它們的大小（比如留下足夠的余量），從而降低彼此入侵帶來的穩(wěn)定性風(fēng)險(xiǎn)。 更有甚者，在二者的邊界上引入一個(gè)特殊值（比如0xDEADBEEF）所充當(dāng)?shù)囊绯?a target="_blank">檢測(cè)”金絲雀（Canary）”——一旦發(fā)現(xiàn)這個(gè)值與預(yù)設(shè)的不同，基本就可以斷定發(fā)生了溢出。

【最安全的“兩面包夾芝士”模型】

---

將“棧（Stack）”和"堆(Heap)"獨(dú)立配置的“兩段式”模型配合邊界金絲雀，為預(yù)防和檢測(cè)堆棧溢出提供了可能。但對(duì)金絲雀的檢測(cè)總歸有種“事后諸葛亮”的感覺，而且很多時(shí)候，我們是想不起來去檢查金絲雀的，比如：棧曾經(jīng)一度跨越雷池入侵到了堆空間，但由于此時(shí)堆恰巧分配出去的RAM不多，沒有與棧發(fā)生實(shí)質(zhì)性的重疊，因而整個(gè)系統(tǒng)“安然無恙”——這只能說是運(yùn)氣好，而風(fēng)險(xiǎn)肯定是存在的——正由于系統(tǒng)“安然無恙”，因此我們?cè)谙到y(tǒng)開發(fā)階段可能不會(huì)想起來去檢查一下金絲雀（有自動(dòng)檢查機(jī)制的RTOS除外），那么這類溢出就有可能被隱藏。

基于上述原因，有沒有一種方法可以：

• 徹底避免棧/堆入侵對(duì)系統(tǒng)的破壞
• 在棧/堆入侵的瞬間就立即表現(xiàn)出來——方便我們?cè)谡{(diào)試階段立即發(fā)現(xiàn)

答案是肯定的，這就是“兩面包夾芝士”模型（此前又叫“三明治”模型）：

從上圖很容易看出：

• 該模型屬于“兩段式模型”的變種
• 與過去堆和棧的“相向生長(zhǎng)”不同，該模型采用了“背向生長(zhǎng)”的方式——避免了棧與堆的相互傷害
• 棧被放在了SRAM的起始位置（Cortex-M從架構(gòu)上鼓勵(lì)將SRAM放置在從0x2000-0000開始的地址上），這樣一旦發(fā)生棧溢出，指針就會(huì)指向SRAM存儲(chǔ)器以外的無效位置——這在大部分芯片上會(huì)觸發(fā)“Bus Fault”，從而產(chǎn)生故障異常——這就實(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)做無事發(fā)生，具體表現(xiàn)為：對(duì)無效地址的寫入操作將被無視，對(duì)無效地址的讀取操作將會(huì)返回0值。具體可以參考芯片手冊(cè)，或者干脆做個(gè)實(shí)驗(yàn)。

---

• 堆被放置在了RAM的最后，中間夾著存放靜態(tài)/全局變量的“RW/ZI區(qū)域”，這也是“兩面包夾芝士”模型（或者“三明治”模型）名稱的由來。這樣的安排也徹底杜絕了棧和堆對(duì)“RW/ZI區(qū)域”發(fā)生入侵的可能。當(dāng)堆溢出時(shí)，與棧類似，對(duì)大部分芯片來說都會(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ù)：

看過我前面一期文章《【嵌入式秘術(shù)】Cortex-M靜態(tài)鏈接庫(kù)——從入坑到入土》的小伙伴一定會(huì)眼前一亮——“原來是這樣啊，我們其實(shí)是手動(dòng)選擇了對(duì)應(yīng)兩段式堆棧模型的庫(kù)版本呢”。 問題是，我們要如何在Arm Compiler環(huán)境下實(shí)現(xiàn)“兩面包夾芝士”模型呢？我們需要寫匯編代碼么？ 不用擔(dān)心，即便你的啟動(dòng)文件是匯編的，具體操作方法也非常簡(jiǎn)單。步驟如下： 步驟一：準(zhǔn)備階段

注意：此步驟只針對(duì)使用匯編啟動(dòng)文件的情況。如果你的啟動(dòng)文件是C，則可跳過該步驟。

在工程管理器中找到你的匯編啟動(dòng)文件，它通常以

startup_<芯片型號(hào)>.s

的形式命名：

找到配置棧和堆大小的部分（紅框標(biāo)注的部分）：

將其整體刪除（或者注釋掉）。注意：請(qǐng)保留這里的 PRESERVE8和THUMB部分。

繼續(xù)移動(dòng)到匯編文件的尾部，找到如下的代碼：

同理，將其刪除（或者注釋掉）。注意：這里要保留 END 。

移動(dòng)到中斷向量表的定義處：

將紅框中所標(biāo)注的代碼選中：

__VectorsDCD__initial_sp

替換為如下內(nèi)容：

                IMPORT   |Image$$ARM_LIB_STACK$$ZI$$Limit|


__VectorsDCD|Image$$ARM_LIB_STACK$$ZI$$Limit|

即：

保存啟動(dòng)文件。

---

此時(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)卡：

首先，一定要確保你勾選了圖中的“Use Memory Layout from Target Dialog”選項(xiàng)。在這一前提下，再次取消對(duì)它的勾選：

我們會(huì)看到，MDK基于當(dāng)前的Memory Layout，為我們?cè)?span style="color:rgb(61,170,214);">Out目錄下生成了一個(gè)與工程同名的鏈接腳本（比如圖中的工程名叫example，因此生成的鏈接腳本為 example.sct）。

單擊 Edit 按鈕，可以看到腳本的內(nèi)容：

先別著急半路開香檳——該文件是系統(tǒng)自動(dòng)生成的，如果我們不移動(dòng)它的位置，那么只要哪次手抖勾選了“Use Memory Layout from Target Dialog”，它的內(nèi)容就會(huì)立即被覆蓋掉——意味著我們?cè)诤罄m(xù)步驟中所做的修改就會(huì)付諸東流。

為了避免該問題，應(yīng)該將它從 Out 目錄中移動(dòng)到工程目錄下。具體步驟為，右鍵單擊腳本文件名：

選擇“Open Container Folder”來打開文件所在目錄：

找到Scatter Script腳本文件后，將其拷貝到上一級(jí)目錄下（也就是工程目錄）：

重新打開工程配置窗口：

確保我們“沒有”選中“Use Memory Layout from Target Dialog”選項(xiàng)，并在Scatter File文本框中直接填寫我們剛剛拷貝出來的腳本文件名（由于我們直接放在工程目錄下，因此這里直接用相對(duì)路徑"./example.scat"或者"example.scat"就行）。單擊OK保存配置。 步驟三：在鏈接腳本中部署堆和棧

在編輯器中打開我們的腳本文件：

圖中選中的部分實(shí)際上包含了RAM中的所有內(nèi)容，包括靜態(tài)變量、全局變量、棧和堆：

是的，你的猜測(cè)沒錯(cuò)：當(dāng)我們沒有特別說明時(shí)，Stack和Heap都以ZI的形式存在于上述空間內(nèi)，其位置任由Linker擺布——這當(dāng)然也帶來了很多不確定性。

接下來我們要做的就是按照我們的設(shè)計(jì)——“兩面包夾芝士”來明確的指定棧和隊(duì)列的大小和位置：

我們要做的是首先將一個(gè)名為ARM_LIB_STACK的execution region放置到RAM的起始位置：

  ARM_LIB_STACK 0x20000000 ALIGN 8 EMPTY 0x800 {}

這里：

• 起始地址是 0x20000000
• STACK的大小是 0x800
• ALIGN 8 指定對(duì)齊是8個(gè)字節(jié)
• EMPTY是必須要保留的，它用來說明 ARM_LIB_STACK 是一個(gè)大數(shù)組，里面默認(rèn)填充了0。
• 如果你想修改填充的內(nèi)容還可以通過關(guān)鍵字 FILL <填充值> 來指定填充的32bit數(shù)值，比如：

 ARM_LIB_STACK 0x20000000 ALIGN 8 FILL 0xDEADBEEF EMPTY 0x800 {}

它實(shí)現(xiàn)了往0x20000000開始的0x800（2KB）大小的棧空間中填充0xDEADBEEF的功能：

熟悉“水印法”測(cè)量棧用量的小伙伴一定大喜。

為了讓ZI/RW緊隨其后——放在STACK的后面，我們需要對(duì) RW_IRAM1 的描述進(jìn)行修改，即從：

RW_IRAM1 0x20000000 0x00020000  {

修改為：

RW_IRAM1+0{

即：

這里，我們?cè)谠痉胖玫刂?strong>0x20000000的位置用"+0"表示“緊隨其后”，并刪除了原本的大小0x00020000——這樣做就是告訴編譯器“RW_IRAM1”不限制大小。

接下來，我們要用類似的方法緊隨 RW_IRAM1 之后放置名為 ARM_LIB_HEAP 的execution region——用來指定堆的位置和大小：

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  {  
   *.o (RESET, +First)
   *(InRoot$$Sections)
   .ANY (+RO)
   .ANY (+XO)
  }


  ARM_LIB_STACK 0x20000000 ALIGN 8 EMPTY 0x800 {}


  ;RW_IRAM1 0x20000000 0x00020000  {  ; RW data
  RW_IRAM1 +0  {  ; RW data
   .ANY (+RW +ZI)
  }


ARM_LIB_HEAP+0ALIGN8EMPTY0x200{}
}

還記得我們前面刪除了原本對(duì)RW_IRAM1的尺寸限制（也就是0x0002000）么？這意味著，現(xiàn)階段的腳本文件對(duì)我們實(shí)際使用的RAM空間是沒有任何限制的——換句話說，如果超出了芯片實(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）
• 綜合來說，上述代碼的作用是在linker的鏈接階段計(jì)算HEAP的終止地址，確認(rèn)它是否落在了RAM的有效范圍內(nèi)。

如果超出了范圍，我們就會(huì)看到如下的編譯錯(cuò)誤：

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)容：

#! armclang --target=arm-arm-none-eabi -mcpu=cortex-m0 -E -xc

然后我們就可以在腳本文件中愉快地使用宏和include了。看到腳本中這么多的常數(shù)了么？地址啊、大小啊，這下都可以用宏替代了。比如：

#define RAM1_SIZE    0x00020000
#define RAM1_BASE    0x20000000
#define RAM1_LIMIT   (RAM1_BASE + RAM1_SIZE)


#define STACK_SIZE   0x800
#define HEAP_SIZE    0x200

其實(shí)我們還可以把宏的定義部分放置到專門的配置頭文件中——通過#include來包含——從而真正做到一個(gè)配置頭文件定天下。 至于宏可以有哪些騷操作，感興趣的小伙伴可以關(guān)注【裸機(jī)思維】公眾號(hào)后，發(fā)送關(guān)鍵字“宏”來獲取相關(guān)文章，這里就不再贅述。

---

需要注意的是：

• 在較新版本的MDK中，上述方法“應(yīng)該”同時(shí)支持Arm Compiler 5（armcc）和Arm Compiler 6（armclang）。你可以關(guān)注【裸機(jī)思維】公眾號(hào)后，發(fā)送關(guān)鍵字“MDK”來獲取最新的MDK。

對(duì)于某些較老的MDK來說，如果你使用的是 Arm Compiler 5，則需要把添加在 scatter script 第一行的命令行修改為：

#! armcc --cpu Cortex-M0 -E
...

以解決可能出現(xiàn)的編譯錯(cuò)誤。

• 如果你的頭文件并沒有“直接”放置在工程目錄下，而是存在一個(gè)相對(duì)路徑，則可以通過在上述命令行中追加 -I <路徑> 的形式來告知編譯器去哪里搜索我們的頭文件。比如：

#!armclang--target=arm-arm-none-eabi-mcpu=cortex-m0-E-xc-I../../cfg

或者

#!armcc--cpuCortex-M0-E-I../../cfg

則是告訴編譯器從相對(duì)路徑 "../../cfg" 下去搜索頭文件。

• 當(dāng)你通過修改頭文件的方式來更新scatter script的內(nèi)容后，第一次編譯，請(qǐng)務(wù)必一定要以“Rebuild All”的形式進(jìn)行，否則你的修改不會(huì)生效。

別說我沒提醒過你哦！

---

【如何把剩余的空間都留給堆】

---

很多時(shí)候，把剩余空間都留給堆是一個(gè)不錯(cuò)的想法，這樣“兩面包夾芝士”模型就獲得了和“單段相向生長(zhǎng)”模型一樣的優(yōu)勢(shì)——配置簡(jiǎn)單。由于我們已經(jīng)有了宏的幫助，借助 ImageLimit() 我們可以將 HEAP_SIZE 的宏定義修改為：

#define HEAP_SIZE    (RAM1_LIMIT - ImageLimit(RW_IRAM1))

它的意思是：用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è)專門來進(jìn)行地址對(duì)齊的函數(shù)：

AlignExpr(<地址數(shù)值>,<對(duì)齊要求>)

比如：

AlignExpr(ImageLimit(RW_IRAM1), 8)

就表示對(duì) RW_IRAM1 的終止地址進(jìn)行 8 字節(jié)對(duì)齊。借助它的幫助，我們可以修改腳本如下：

#defineHEAP_SIZE
    (RAM1_LIMIT-AlignExpr(ImageLimit(RW_IRAM1),8))

即：

再編譯時(shí)，已然沒有問題。

【如何隨時(shí)隨地的了解棧的最大使用情況】

---

水印法是實(shí)現(xiàn)“最大棧用量統(tǒng)計(jì)”的最有效方式。其原理也不復(fù)雜：

1. 先用指定的水印常數(shù)（比如 0xDEADBEEF）將整個(gè)棧填滿；
2. 從棧空間的最初頂部（棧存儲(chǔ)空間的終止地址）向下開始搜索之前填充的水印常數(shù)——一旦碰到水印，就將當(dāng)前已經(jīng)經(jīng)歷過的RAM總量作為棧的最大深度（最大用量）；

對(duì)于步驟1來說，可以通過前面介紹的 FILL 關(guān)鍵字來完成對(duì)棧空間的填充：

ARM_LIB_STACK0x20000000ALIGN8FILL0xDEADBEEFEMPTYSTACK_SIZE
{
}

然后借助下面的代碼完成統(tǒng)計(jì)工作：

#if defined(__clang__)
#   pragma clang diagnostic push
#   pragma clang diagnostic ignored "-Wdollar-in-identifier-extension"
#   pragma clang diagnostic ignored "-Wdouble-promotion"
#endif
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;
}
#if defined(__clang__)
#   pragma clang diagnostic pop
#endif

這里有幾點(diǎn)需要說明一下：

• armlink 為我們提供了通用的語(yǔ)法來獲取 execution region 的起始地址、大小和終止地址：

extern uint32_t Image$$$$Base[];
externuint32_tImage$$$$Length;
extern uint32_t Image$$$$Limit[];

這里，Base和Limit被定義成了不定長(zhǎng)數(shù)組的形式，因此我們可以直接把它們當(dāng)做常量指針來使用——獲取所需的地址。Length被定義成了一個(gè)普通的uint32_t型的變量，按照官方文檔的要求，雖然很反直覺，但如果要獲取它的值——也就是對(duì)應(yīng)execution region的大小，必須要對(duì)其進(jìn)行&操作，并隨后強(qiáng)制轉(zhuǎn)化為整形數(shù)值。這么說也許有點(diǎn)抽象，不妨對(duì)照前面的代碼來看：

#include 
...
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;

這里，我們通過 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的操作：

#if defined(__clang__)
#   pragma clang diagnostic push
#   pragma clang diagnostic ignored "-Wdollar-in-identifier-extension"
#   pragma clang diagnostic ignored "-Wdouble-promotion"
#endif
uint32_t calculate_stack_usage_topdown(void)
{
    ...
}
#if defined(__clang__)
#pragmaclangdiagnosticpop
#endif

而 -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ù)”——一旦碰到，就可以用已知的棧空間尺寸減去已經(jīng)經(jīng)歷過的RAM總量作為棧的最大深度（最大用量）。

該方法的優(yōu)點(diǎn)是：不容易發(fā)生誤判；缺點(diǎn)是：當(dāng)棧空間很大而實(shí)際棧用量較小時(shí)往往較為耗時(shí)。對(duì)應(yīng)的代碼如下：

#if defined(__clang__)
#   pragma clang diagnostic push
#   pragma clang diagnostic ignored "-Wdollar-in-identifier-extension"
#   pragma clang diagnostic ignored "-Wdouble-promotion"
#endif
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;
}
#if defined(__clang__)
#   pragma clang diagnostic pop
#endif

【后記】

---

在這篇文章中，我們介紹了棧和堆在存儲(chǔ)器中的常見排布模型，比較了它們的優(yōu)劣，并提出了一種被稱為“兩面包夾芝士”的兩段式模型。該模型：

• 可以有效避免堆棧溢出破壞常規(guī)變量
• 溢出發(fā)生時(shí)可以在大部分芯片中第一時(shí)間觸發(fā)異常——被我們捕捉到

后面，我們以MDK為例介紹了如何在Arm Compiler環(huán)境下應(yīng)用這一模型，并引入了使用宏對(duì)其進(jìn)行進(jìn)一步拓展的方法。

值得說明的是，這一方法對(duì)Arm Compiler 5（armcc）和Arm Compiler 6（armclang）同樣適用。支持MicroLib和非MicroLib的情況。無論啟動(dòng)文件是否為匯編，都可以正常工作。

實(shí)際上，使用鏈接腳本而非匯編啟動(dòng)文件來對(duì)兩段式堆棧模型進(jìn)行配置是Arm公司一直以來所提倡的。隨著Arm Compiler 6的逐步普及，更多的芯片公司正在追隨Arm的腳步將原本的匯編啟動(dòng)文件替換為 CMSIS 目錄下所提倡的純C語(yǔ)言啟動(dòng)文件。

作為【反復(fù)橫跳】系列的一部分，我希望通過這篇文章能幫助大家掃清從Arm Compiler 5向Arm Compiler 6過渡圖中與棧相關(guān)的障礙。希望對(duì)你有所幫助。