【说在前面的话】
在中文嵌入式环境中,时不时的总能看到不少朋友”堆”“栈“傻傻分不清楚,我很早之前在文章《漫谈C变量——夏虫不可语冰》介绍过二者的区别,这里就不再深入展开,总之:
栈(Stack)“是我们用来分配局部变量、实现函数调用和在异常响应时保存被打断代码上下文的地方——具体细节不重要,在本文的讨论中,我们只需要记住以下信息:
- Cortex-M系统栈的生长方向是自上而下的,也就是随着更多内容被压入(PUSH)栈中,栈顶指针的地址值是越来越小的——也就是从地址值较大的位置向地址值较小的位置移动。
- Cortex-M的栈顶指针指向的是“栈顶部的空位”。
- 从最大兼容性角度考虑,Cortex-M架构下栈存储空间必须对齐到8字节。
“堆(Heap)”是我们使用 malloc 申请动态存储空间时所必须用到的一种数据结构——通常由C语言的系统库提供。
- 堆本身只是一个内存管理的算法,它所要管理的RAM空间需要用户通过某种手段将指定大小的RAM空间交到Heap算法手里。
- 与栈不同,堆的生长方向其实完全由具体的管理算法决定,而堆的算法数量虽然不能说是灿若星辰,至少一双手肯定数不过来——但一般来说我们可以大体认为堆的生长方向是“自下而上的”——也就是从地址值较小的位置延伸到地址值较大的位置。
- 堆的对齐要求一般是4字节起步,8字节更好,情况不明的直接就32个字节吧。
【常见的堆栈模型】
从单纯从我不负责任的经验来看,由很多GCC领衔使用的“对向生长”模型可能是嵌入式领域最常见的”大聪明模型“,没有之一。如下图所示:
先说优点吧:
- 该模型栈和堆共用同一块连续的地址区间
- 配置时不需要操心具体栈有多大、堆有多大
- 配置方法简单:只需要指定这一整块”堆栈“区域的起始地址,以及这一整块堆栈区域的大小
- 堆和栈的最大可用大小是此消彼长的,理论上可以在某种最优的情况下达到动态的”此消彼长“,可以获得理想状下最大的空间复用效率。
缺点也很明显:
- 堆和栈的最大可用大小是此消彼长的,在真实场景中,由于”你长我也长谁怕谁”的情况居多,发生随机性的“双向奔赴”从而进行“负距离”的互动可能性从理论上就不可避免,因而是系统稳定性的“一生之敌”。
- 实验室里7x24小时完美通过,一去客户那里就随机性宕机的“挖坑之王”。
为了提高系统稳定性,人们简单地将“堆”和“栈”拆开来单独配置,就获得了常见的“两段式堆栈模型”:
可以看到,相较之前的模型,虽然仍然是“对向生长”,但由于栈和堆有了自己固定空间,因此可以方便地根据实际用量调整它们的大小(比如留下足够的余量),从而降低彼此入侵带来的稳定性风险。
更有甚者,在二者的边界上引入一个特殊值(比如0xDEADBEEF)所充当的溢出检测”金丝雀(Canary)”——一旦发现这个值与预设的不同,基本就可以断定发生了溢出。
【最安全的“两面包夹芝士”模型】
将“栈(Stack)”和"堆(Heap)"独立配置的“两段式”模型配合边界金丝雀,为预防和检测堆栈溢出提供了可能。但对金丝雀的检测总归有种“事后诸葛亮”的感觉,而且很多时候,我们是想不起来去检查金丝雀的,比如:栈曾经一度跨越雷池入侵到了堆空间,但由于此时堆恰巧分配出去的RAM不多,没有与栈发生实质性的重叠,因而整个系统“安然无恙”——这只能说是运气好,而风险肯定是存在的——正由于系统“安然无恙”,因此我们在系统开发阶段可能不会想起来去检查一下金丝雀(有自动检查机制的RTOS除外),那么这类溢出就有可能被隐藏。
基于上述原因,有没有一种方法可以:
- 彻底避免栈/堆入侵对系统的破坏
- 在栈/堆入侵的瞬间就立即表现出来——方便我们在调试阶段立即发现
答案是肯定的,这就是“两面包夹芝士”模型(此前又叫“三明治”模型):
从上图很容易看出:
- 该模型属于“两段式模型”的变种
- 与过去堆和栈的“相向生长”不同,该模型采用了“背向生长”的方式——避免了栈与堆的相互伤害
- 栈被放在了SRAM的起始位置(Cortex-M从架构上鼓励将SRAM放置在从0x2000-0000开始的地址上),这样一旦发生栈溢出,指针就会指向SRAM存储器以外的无效位置——这在大部分芯片上会触发“Bus Fault”,从而产生故障异常——这就实现了对栈溢出的当场捕获,并且不依赖MPU或者“栈底地址限制检测(Stack Limit Checking)”之类的架构特性。
当然有些芯片设计者可能会选择“隐藏这类错误”,不仅不会触发异常,而且会当做无事发生,具体表现为:对无效地址的写入操作将被无视,对无效地址的读取操作将会返回0值。具体可以参考芯片手册,或者干脆做个实验。
- 堆被放置在了RAM的最后,中间夹着存放静态/全局变量的“RW/ZI区域”,这也是“两面包夹芝士”模型(或者“三明治”模型)名称的由来。这样的安排也彻底杜绝了栈和堆对“RW/ZI区域”发生入侵的可能。当堆溢出时,与栈类似,对大部分芯片来说都会触发故障异常,从而在开发调试阶段第一时间被我们所捕获。
- 通过链接脚本(比如Arm Compiler的Scatter Script或者gcc、clang的ld)的一些运算功能,我们甚至可以做到“将剩下的空间全留给HEAP”,从而简化系统的配置。
【Arm官方低调推荐的”新“方法】
其实,Arm Compiler 在很久之前就逐步淘汰了“大聪明的单段对向生长模型”,而“两段模型”早已成为主流。比如,我们在汇编启动文件中经常可以见到这样的代码片段:
这就是“两段式”模型的证据。实际上,在启动代码的尾部,汇编程序通过:
IMPORT __use_two_region_memory
选择了对两段式模型提供支持的libc库:
看过我前面一期文章《【嵌入式秘术】Cortex-M静态链接库——从入坑到入土》的小伙伴一定会眼前一亮——“原来是这样啊,我们其实是手动选择了对应两段式堆栈模型的库版本呢”。
问题是,我们要如何在Arm Compiler环境下实现“两面包夹芝士”模型呢?我们需要写汇编代码么?
不用担心,即便你的启动文件是汇编的,具体操作方法也非常简单。步骤如下:
步骤一:准备阶段
注意:此步骤只针对使用汇编启动文件的情况。如果你的启动文件是C,则可跳过该步骤。
在工程管理器中找到你的汇编启动文件,它通常以
startup_<芯片型号>.s
的形式命名:
找到配置栈和堆大小的部分(红框标注的部分):
将其整体删除(或者注释掉)。
注意:请保留这里的 PRESERVE8和THUMB部分。
继续移动到汇编文件的尾部,找到如下的代码:
同理,将其删除(或者注释掉)。
注意:这里要保留 END 。
移动到中断向量表的定义处:
将红框中所标注的代码选中:
__Vectors DCD __initial_sp
替换为如下内容:
IMPORT |Image$$ARM_LIB_STACK$$ZI$$Limit|
即:
保存启动文件。
即:
Error: L6218E: Undefined symbol __initial_sp (referred from entry2.o).
或者你没有开启 microLib,则会看到一个不同的错误:
即:
Error: L6915E: Library reports error: The semihosting __user_initial_stackheap cannot reliably set up a usable heap region if scatter loading is in use
这都是正常的,不必惊慌。这类错误会在完成后面的步骤后自然消失。
步骤二:获取链接脚本(Scatter Script)
打开工程配置窗口“Options for Target”,切换到“Linker”选项卡:
首先,一定要确保你勾选了图中的“Use Memory Layout from Target Dialog”选项。在这一前提下,再次取消对它的勾选:
我们会看到,MDK基于当前的Memory Layout,为我们在Out目录下生成了一个与工程同名的链接脚本(比如图中的工程名叫example,因此生成的链接脚本为example.sct)。
单击Edit按钮,可以看到脚本的内容:
先别着急半路开香槟——该文件是系统自动生成的,如果我们不移动它的位置,那么只要哪次手抖勾选了“Use Memory Layout from Target Dialog”,它的内容就会立即被覆盖掉——意味着我们在后续步骤中所做的修改就会付诸东流。
为了避免该问题,应该将它从 Out 目录中移动到工程目录下。具体步骤为,右键单击脚本文件名:
选择“Open Container Folder”来打开文件所在目录:
找到Scatter Script脚本文件后,将其拷贝到上一级目录下(也就是工程目录):
重新打开工程配置窗口:
确保我们“没有”选中“Use Memory Layout from Target Dialog”选项,并在Scatter File文本框中直接填写我们刚刚拷贝出来的脚本文件名(由于我们直接放在工程目录下,因此这里直接用相对路径"./example.scat"或者"example.scat"就行)。单击OK保存配置。
步骤三:在链接脚本中部署堆和栈
在编辑器中打开我们的脚本文件:
图中选中的部分实际上包含了RAM中的所有内容,包括静态变量、全局变量、栈和堆:
是的,你的猜测没错:当我们没有特别说明时,Stack和Heap都以ZI的形式存在于上述空间内,其位置任由Linker摆布——这当然也带来了很多不确定性。
接下来我们要做的就是按照我们的设计——“两面包夹芝士”来明确的指定栈和队列的大小和位置:
我们要做的是首先将一个名为ARM_STACK_LIB的execution region放置到RAM的起始位置:
ARM_LIB_STACK 0x20000000 ALIGN 8 EMPTY 0x800 {}
这里:
- 起始地址是0x20000000
- STACK的大小是0x800
- ALIGN 8指定对齐是8个字节
- EMPTY是必须要保留的,它用来说明ARM_LIB_STACK是一个大数组,里面默认填充了0。
- 如果你想修改填充的内容还可以通过关键字FILL <填充值>来指定填充的32bit数值,比如:
ARM_LIB_STACK 0x20000000 ALIGN 8 FILL 0xDEADBEEF EMPTY 0x800 {}
它实现了往0x20000000开始的0x800(2KB)大小的栈空间中填充0xDEADBEEF的功能:
熟悉“水印法”测量栈用量的小伙伴一定大喜。
为了让ZI/RW紧随其后——放在STACK的后面,我们需要对 RW_IRAM1 的描述进行修改,即从:
RW_IRAM1 0x20000000 0x00020000 {
修改为:
RW_IRAM1 +0 {
即:
这里,我们在原本放置地址0x20000000的位置用"+0"表示“紧随其后”,并删除了原本的大小0x00020000——这样做就是告诉编译器“RW_IRAM1”不限制大小。
接下来,我们要用类似的方法紧随 RW_IRAM1 之后放置名为 ARM_LIB_HEAP 的execution region——用来指定堆的位置和大小:
ARM_LIB_HEAP +0 ALIGN 8 EMPTY 0x200 {}
可以看到,这里与栈的设置方式几乎一样,而“+0”则同样告诉linker:请将HEAP紧邻前面的 RW_IRAM1 放置。最终的效果如下:
LR_IROM1 0x00000000 0x00040000 {
还记得我们前面删除了原本对RW_IRAM1的尺寸限制(也就是0x0002000)么?这意味着,现阶段的脚本文件对我们实际使用的RAM空间是没有任何限制的——换句话说,如果超出了芯片实际的SRAM大小,编译器也是不会报告错误的。为了重新加入这一限制,我们可以在 ARM_LIB_HEAP的后面加入下面的语句:
ScatterAssert(ImageLimit(ARM_LIB_HEAP) <= 0x20000000 + 0x20000)
这里:
- ScatterAssert()是让linker对括号中的内容进行检查
- ImageLimit()是在编译时刻获得括号内指定 execution region 的终止地址
- 0x20000000+0x20000 是例子中整个RAM的终止地址(这里假设RAM从0x20000000开始,大小是0x20000)
- 综合来说,上述代码的作用是在linker的链接阶段计算HEAP的终止地址,确认它是否落在了RAM的有效范围内。
如果超出了范围,我们就会看到如下的编译错误:
Error: L6388E: ScatterAssert expression (ImageLimit(ARM_LIB_HEAP) <= 0x20000000 + 0x20000) failed on line 22 : (0x20001220 <= 0x20020000)
最终效果如下:
对应的“两面包夹芝士”图示如下:
编译工程:
【“虽迟但到”的宏和头文件】
是的,你猜得没错,我们可以在链接脚本中使用编译预处理,这意味着:
- 我们可以使用宏
- 我们可以include头文件
- 我们可以进行条件编译
具体方法并不难,只需要在链接脚本的“第一行”,注意一定要是第一行(Number One)——前面不能有任何内容,空行或者注释都不行——放置如下的内容:
#! armclang --target=arm-arm-none-eabi -mcpu=cortex-m0 -E -xc
然后我们就可以在脚本文件中愉快地使用宏和include了。看到脚本中这么多的常数了么?地址啊、大小啊,这下都可以用宏替代了。比如:
#define RAM1_SIZE 0x00020000
其实我们还可以把宏的定义部分放置到专门的配置头文件中——通过#include来包含——从而真正做到一个配置头文件定天下。
【如何把剩余的空间都留给堆】
很多时候,把剩余空间都留给堆是一个不错的想法,这样“两面包夹芝士”模型就获得了和“单段相向生长”模型一样的优势——配置简单。由于我们已经有了宏的帮助,借助ImageLimit()我们可以将 HEAP_SIZE 的宏定义修改为:
#define HEAP_SIZE (RAM1_LIMIT - ImageLimit(RW_IRAM1))
它的意思是:用RAM1的终止地址减去RW_IRAM1的终止地址,获得中间的差额,其图示如下:
【后记】
在这篇文章中,我们介绍了栈和堆在存储器中的常见排布模型,比较了它们的优劣,并提出了一种被称为“两面包夹芝士”的两段式模型。该模型:
- 可以有效避免堆栈溢出破坏常规变量
- 溢出发生时可以在大部分芯片中第一时间触发异常——被我们捕捉到
后面,我们以MDK为例介绍了如何在Arm Compiler环境下应用这一模型,并引入了使用宏对其进行进一步拓展的方法。
值得说明的是,这一方法对Arm Compiler 5(armcc)和Arm Compiler 6(armclang)同样适用。支持MicroLib和非MicroLib的情况。无论启动文件是否为汇编,都可以正常工作。
实际上,使用链接脚本而非汇编启动文件来对两段式堆栈模型进行配置是Arm公司一直以来所提倡的。随着Arm Compiler 6的逐步普及,更多的芯片公司正在追随Arm的脚步将原本的汇编启动文件替换为 CMSIS 目录下所提倡的纯C语言启动文件。
作为【反复横跳】系列的一部分,我希望通过这篇文章能帮助大家扫清从Arm Compiler 5向Arm Compiler 6过渡图中与栈相关的障碍。希望对你有所帮助。
原文: 裸机思维
作者:GorgonMeducer 傻孩子
专栏推荐文章
- 【玩转Arm-2D】八、实战篇 - 手撸酷炫智能手表GUI
- 【玩转Arm-2D】七、制作酷炫环形进度条
- 【喂到嘴边了的模块】超级嵌入式系统“性能/时间”工具箱
- 【喂到嘴边了的模块】关于我在MDK中部署LVGL只用了5分钟这件小事
如果你喜欢我的思维,欢迎订阅裸机思维欢迎添加极术小姐姐微信(id:aijishu20)加入技术交流群,请备注研究方向。