26

傻孩子(GorgonMeducer) · 2022年11月15日 · 北京市

【反复横跳】从AC5到AC6的转型之路(2)——“两面包夹芝士”的堆栈模型

image.png
【说在前面的话】


在中文嵌入式环境中,时不时的总能看到不少朋友”堆”“栈“傻傻分不清楚,我很早之前在文章《漫谈C变量——夏虫不可语冰》介绍过二者的区别,这里就不再深入展开,总之:

栈(Stack)“是我们用来分配局部变量、实现函数调用和在异常响应时保存被打断代码上下文的地方——具体细节不重要,在本文的讨论中,我们只需要记住以下信息:

  • Cortex-M系统栈的生长方向是自上而下的,也就是随着更多内容被压入(PUSH)栈中,栈顶指针的地址值是越来越小的——也就是从地址值较大的位置向地址值较小的位置移动。
  • Cortex-M的栈顶指针指向的是“栈顶部的空位”
  • 从最大兼容性角度考虑,Cortex-M架构下栈存储空间必须对齐到8字节。

image.png
“堆(Heap)”是我们使用 malloc 申请动态存储空间时所必须用到的一种数据结构——通常由C语言的系统库提供。

  • 堆本身只是一个内存管理的算法,它所要管理的RAM空间需要用户通过某种手段将指定大小的RAM空间交到Heap算法手里
  • 与栈不同,堆的生长方向其实完全由具体的管理算法决定,而堆的算法数量虽然不能说是灿若星辰,至少一双手肯定数不过来——但一般来说我们可以大体认为堆的生长方向是“自下而上的”——也就是从地址值较小的位置延伸到地址值较大的位置。
  • 堆的对齐要求一般是4字节起步,8字节更好,情况不明的直接就32个字节吧
    image.png

【常见的堆栈模型】


从单纯从我不负责任的经验来看,由很多GCC领衔使用的“对向生长”模型可能是嵌入式领域最常见的”大聪明模型“,没有之一。如下图所示:

image.png

先说优点吧:

  • 该模型栈和堆共用同一块连续的地址区间
  • 配置时不需要操心具体栈有多大、堆有多大
  • 配置方法简单:只需要指定这一整块”堆栈“区域的起始地址,以及这一整块堆栈区域的大小
  • 堆和栈的最大可用大小是此消彼长的,理论上可以在某种最优的情况下达到动态的”此消彼长“,可以获得理想状下最大的空间复用效率。

缺点也很明显:

  • 堆和栈的最大可用大小是此消彼长的,在真实场景中,由于”你长我也长谁怕谁”的情况居多,发生随机性的“双向奔赴”从而进行“负距离”的互动可能性从理论上就不可避免,因而是系统稳定性的“一生之敌”
  • 实验室里7x24小时完美通过,一去客户那里就随机性宕机的“挖坑之王”

image.png

为了提高系统稳定性,人们简单地将“堆”和“栈”拆开来单独配置,就获得了常见的“两段式堆栈模型”:

image.png

可以看到,相较之前的模型,虽然仍然是“对向生长”,但由于栈和堆有了自己固定空间,因此可以方便地根据实际用量调整它们的大小(比如留下足够的余量),从而降低彼此入侵带来的稳定性风险。

更有甚者,在二者的边界上引入一个特殊值(比如0xDEADBEEF)所充当的溢出检测”金丝雀(Canary)”——一旦发现这个值与预设的不同,基本就可以断定发生了溢出。
image.png
【最安全的“两面包夹芝士”模型】


将“栈(Stack)”和"堆(Heap)"独立配置的“两段式”模型配合边界金丝雀,为预防和检测堆栈溢出提供了可能。但对金丝雀的检测总归有种“事后诸葛亮”的感觉,而且很多时候,我们是想不起来去检查金丝雀的,比如:栈曾经一度跨越雷池入侵到了堆空间,但由于此时堆恰巧分配出去的RAM不多,没有与栈发生实质性的重叠,因而整个系统“安然无恙”——这只能说是运气好,而风险肯定是存在的——正由于系统“安然无恙”,因此我们在系统开发阶段可能不会想起来去检查一下金丝雀(有自动检查机制的RTOS除外),那么这类溢出就有可能被隐藏。

基于上述原因,有没有一种方法可以:

  • 彻底避免栈/堆入侵对系统的破坏
  • 在栈/堆入侵的瞬间就立即表现出来——方便我们在调试阶段立即发现

答案是肯定的,这就是“两面包夹芝士”模型(此前又叫“三明治”模型):

image.png

从上图很容易看出:

  • 该模型属于“两段式模型”的变种
  • 与过去堆和栈的“相向生长”不同,该模型采用了“背向生长”的方式——避免了栈与堆的相互伤害
  • 栈被放在了SRAM的起始位置(Cortex-M从架构上鼓励将SRAM放置在从0x2000-0000开始的地址上),这样一旦发生栈溢出,指针就会指向SRAM存储器以外的无效位置——这在大部分芯片上会触发“Bus Fault”,从而产生故障异常——这就实现了对栈溢出的当场捕获,并且不依赖MPU或者“栈底地址限制检测(Stack Limit Checking)”之类的架构特性。

当然有些芯片设计者可能会选择“隐藏这类错误”,不仅不会触发异常,而且会当做无事发生,具体表现为:对无效地址的写入操作将被无视,对无效地址的读取操作将会返回0值。具体可以参考芯片手册,或者干脆做个实验。


  • 堆被放置在了RAM的最后,中间夹着存放静态/全局变量的“RW/ZI区域”,这也是“两面包夹芝士”模型(或者“三明治”模型)名称的由来。这样的安排也彻底杜绝了栈和堆对“RW/ZI区域”发生入侵的可能。当堆溢出时,与栈类似,对大部分芯片来说都会触发故障异常,从而在开发调试阶段第一时间被我们所捕获。

image.png

  • 通过链接脚本(比如Arm Compiler的Scatter Script或者gcc、clang的ld)的一些运算功能,我们甚至可以做到“将剩下的空间全留给HEAP”,从而简化系统的配置。

image.png

【Arm官方低调推荐的”新“方法】


其实,Arm Compiler 在很久之前就逐步淘汰了“大聪明的单段对向生长模型”,而“两段模型”早已成为主流。比如,我们在汇编启动文件中经常可以见到这样的代码片段:

image.png

这就是“两段式”模型的证据。实际上,在启动代码的尾部,汇编程序通过:

IMPORT __use_two_region_memory

选择了对两段式模型提供支持的libc库:

image.png

看过我前面一期文章《【嵌入式秘术】Cortex-M静态链接库——从入坑到入土》的小伙伴一定会眼前一亮——“原来是这样啊,我们其实是手动选择了对应两段式堆栈模型的库版本呢”
image.png
问题是,我们要如何在Arm Compiler环境下实现“两面包夹芝士”模型呢?我们需要写汇编代码么?

不用担心,即便你的启动文件是汇编的,具体操作方法也非常简单。步骤如下:

步骤一:准备阶段

注意:此步骤只针对使用汇编启动文件的情况。如果你的启动文件是C,则可跳过该步骤。

在工程管理器中找到你的汇编启动文件,它通常以 

startup_<芯片型号>.s

的形式命名:
image.png
找到配置栈和堆大小的部分(红框标注的部分):
image.png
将其整体删除(或者注释掉)。

注意:请保留这里的 PRESERVE8和THUMB部分。

继续移动到汇编文件的尾部,找到如下的代码:

image.png

同理,将其删除(或者注释掉)。

注意:这里要保留 END 。

移动到中断向量表的定义处:

image.png

将红框中所标注的代码选中:

__Vectors       DCD      __initial_sp

替换为如下内容:

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

即:
image.png
保存启动文件。


image.png
即:

Error: L6218E: Undefined symbol __initial_sp (referred from entry2.o).

或者你没有开启 microLib,则会看到一个不同的错误:
image.png

即:

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”选项卡:

image.png

首先,一定要确保你勾选了图中的“Use Memory Layout from Target Dialog”选项。在这一前提下,再次取消对它的勾选:
image.png
我们会看到,MDK基于当前的Memory Layout,为我们在Out目录下生成了一个与工程同名的链接脚本(比如图中的工程名叫example,因此生成的链接脚本为example.sct)。

单击Edit按钮,可以看到脚本的内容:
image.png
先别着急半路开香槟——该文件是系统自动生成的,如果我们不移动它的位置,那么只要哪次手抖勾选了“Use Memory Layout from Target Dialog”,它的内容就会立即被覆盖掉——意味着我们在后续步骤中所做的修改就会付诸东流。
image.png
为了避免该问题,应该将它从 Out 目录中移动到工程目录下。具体步骤为,右键单击脚本文件名:
image.png
选择“Open Container Folder”来打开文件所在目录:
image.png
找到Scatter Script脚本文件后,将其拷贝到上一级目录下(也就是工程目录):
image.png

重新打开工程配置窗口:

image.png

确保我们“没有”选中“Use Memory Layout from Target Dialog”选项,并在Scatter File文本框中直接填写我们刚刚拷贝出来的脚本文件名(由于我们直接放在工程目录下,因此这里直接用相对路径"./example.scat"或者"example.scat"就行)。单击OK保存配置。

步骤三:在链接脚本中部署堆和栈

在编辑器中打开我们的脚本文件:

image.png

图中选中的部分实际上包含了RAM中的所有内容,包括静态变量、全局变量、栈和堆:

image.png

是的,你的猜测没错:当我们没有特别说明时,Stack和Heap都以ZI的形式存在于上述空间内,其位置任由Linker摆布——这当然也带来了很多不确定性

接下来我们要做的就是按照我们的设计——“两面包夹芝士”来明确的指定栈和队列的大小和位置:

image.png

我们要做的是首先将一个名为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的功能:
image.png
熟悉“水印法”测量栈用量的小伙伴一定大喜。

为了让ZI/RW紧随其后——放在STACK的后面,我们需要对 RW_IRAM1 的描述进行修改,即从:

RW_IRAM1 0x20000000 0x00020000  {

修改为:

RW_IRAM1 +0  {

即:
image.png
这里,我们在原本放置地址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  {    

image.png

还记得我们前面删除了原本对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)

最终效果如下:
image.png
对应的“两面包夹芝士”图示如下:
image.png
编译工程:
image.png

【“虽迟但到”的宏和头文件】


是的,你猜得没错,我们可以在链接脚本中使用编译预处理,这意味着:

  • 我们可以使用宏
  • 我们可以include头文件
  • 我们可以进行条件编译

具体方法并不难,只需要在链接脚本的“第一行”,注意一定要是第一行(Number One)——前面不能有任何内容,空行或者注释都不行——放置如下的内容:

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

image.png

然后我们就可以在脚本文件中愉快地使用宏和include了。看到脚本中这么多的常数了么?地址啊、大小啊,这下都可以用宏替代了。比如:

#define RAM1_SIZE    0x00020000

image.png

其实我们还可以把宏的定义部分放置到专门的配置头文件中——通过#include来包含——从而真正做到一个配置头文件定天下。

【如何把剩余的空间都留给堆】


很多时候,把剩余空间都留给堆是一个不错的想法,这样“两面包夹芝士”模型就获得了和“单段相向生长”模型一样的优势——配置简单。由于我们已经有了宏的帮助,借助ImageLimit()我们可以将 HEAP_SIZE 的宏定义修改为:

#define HEAP_SIZE    (RAM1_LIMIT - ImageLimit(RW_IRAM1))

它的意思是:用RAM1的终止地址减去RW_IRAM1的终止地址,获得中间的差额,其图示如下:
image.png

image.png

【后记】


在这篇文章中,我们介绍了栈和堆在存储器中的常见排布模型,比较了它们的优劣,并提出了一种被称为“两面包夹芝士”的两段式模型。该模型:

  • 可以有效避免堆栈溢出破坏常规变量
  • 溢出发生时可以在大部分芯片中第一时间触发异常——被我们捕捉到

后面,我们以MDK为例介绍了如何在Arm Compiler环境下应用这一模型,并引入了使用宏对其进行进一步拓展的方法。

值得说明的是,这一方法对Arm Compiler 5(armcc)Arm Compiler 6(armclang)同样适用。支持MicroLib和非MicroLib的情况。无论启动文件是否为汇编,都可以正常工作。

实际上,使用链接脚本而非汇编启动文件来对两段式堆栈模型进行配置是Arm公司一直以来所提倡的。随着Arm Compiler 6的逐步普及,更多的芯片公司正在追随Arm的脚步将原本的汇编启动文件替换为 CMSIS 目录下所提倡的纯C语言启动文件。

作为【反复横跳】系列的一部分,我希望通过这篇文章能帮助大家扫清从Arm Compiler 5Arm Compiler 6过渡图中与栈相关的障碍。希望对你有所帮助。


原文: 裸机思维
作者:GorgonMeducer 傻孩子

专栏推荐文章

如果你喜欢我的思维,欢迎订阅裸机思维欢迎添加极术小姐姐微信(id:aijishu20)加入技术交流群,请备注研究方向。
推荐阅读
关注数
1479
内容数
116
探讨嵌入式系统开发的相关思维、方法、技巧。
目录
极术微信服务号
关注极术微信号
实时接收点赞提醒和评论通知
安谋科技学堂公众号
关注安谋科技学堂
实时获取安谋科技及 Arm 教学资源
安谋科技招聘公众号
关注安谋科技招聘
实时获取安谋科技中国职位信息