99%开发者从未听说过的堆栈模型

描述

 


  朋友:  你知道如何设置栈最安全么?你知道如何不写一行汇编代码就能设置栈的大小么?你知道如何在链接脚本中使用宏和头文件么?你知道如何在代码中随时随地检查栈的最大使用情况么?   本文从理论到实践,从知其然到知其所以然,一杯奶茶的功夫就给你讲得明明白白。  

 

  在中文嵌入式环境中,时不时的总能看到不少朋友”堆”“栈“傻傻分不清楚,我很早之前在文章《漫谈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|


__Vectors       DCD      |Image$$ARM_LIB_STACK$$ZI$$Limit|
即:

嵌入式

保存启动文件。  

此时,如果你着急编译,当你当你开启了microLib时,很可能会看到如下的链接错误:

嵌入式

即:
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_LIB_STACK 的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:请将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 +0 ALIGN 8 EMPTY 0x200 {}
}

嵌入式

还记得我们前面删除了原本对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
#define RAM1_BASE    0x20000000
#define RAM1_LIMIT   (RAM1_BASE + RAM1_SIZE)


#define STACK_SIZE   0x800
#define HEAP_SIZE    0x200
 

嵌入式

其实我们还可以把宏的定义部分放置到专门的配置头文件中——通过#include来包含——从而真正做到一个配置头文件定天下。 至于宏可以有哪些骚操作,感兴趣的小伙伴可以关注【裸机思维】公众号后,发送关键字“”来获取相关文章,这里就不再赘述。    
需要注意的是:  
  • 在较新版本的MDK中,上述方法“应该”同时支持Arm Compiler 5(armcc)Arm Compiler 6(armclang)。你可以关注【裸机思维】公众号后,发送关键字“MDK”来获取最新的MDK。
对于某些较老的MDK来说,如果你使用的是 Arm Compiler 5,则需要把添加在 scatter script 第一行的命令行修改为:
#! armcc --cpu Cortex-M0 -E
...

以解决可能出现的编译错误。

  • 如果你的头文件并没有“直接”放置在工程目录下,而是存在一个相对路径,则可以通过在上述命令行中追加 -I <路径> 的形式来告知编译器去哪里搜索我们的头文件。比如:
#! armclang --target=arm-arm-none-eabi -mcpu=cortex-m0 -E -xc -I ../../cfg

或者

#! armcc --cpu Cortex-M0 -E -I ../../cfg

则是告诉编译器从相对路径 "../../cfg" 下去搜索头文件。

 

 

  • 当你通过修改头文件的方式来更新scatter script的内容后,第一次编译,请务必一定要以“Rebuild All”的形式进行,否则你的修改不会生效。

 

别说我没提醒过你哦!


   

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


很多时候,把剩余空间都留给堆是一个不错的想法,这样“两面包夹芝士”模型就获得了和“单段相向生长”模型一样的优势——配置简单。由于我们已经有了宏的帮助,借助 ImageLimit() 我们可以将 HEAP_SIZE 的宏定义修改为:
#define HEAP_SIZE    (RAM1_LIMIT - ImageLimit(RW_IRAM1))
它的意思是:用RAM1的终止地址减去 RW_IRAM1的终止地址,获得中间的差额,其图示如下:  

嵌入式

看似完美,有的小伙伴一编译就会报告如下的错误:

嵌入式

即:

Error: L6388E: ScatterAssert expression (ImageLimit(ARM_LIB_HEAP) <= (0x20000000 + 0x20000)) failed on line 29 : (0x20020004 <= 0x20020000)

奇怪,我们的计算公式应该没错啊——Heap的尺寸应该就是使用整个 RAM的终止地址减去 RW_IRAM1 的终止地址啊,为什么提示差4个字节呢?

聪明的小伙伴一定已经注意到了,我们在 ARM_LIB_HEAP 的定义中,指定了其首地址的对齐为8字节:

ARM_LIB_HEAP +0 ALIGN 8 EMPTY HEAP_SIZE {}

RW_IRAM1 的尺寸不一定是8的整倍数,当它只是“4的整倍数”而不满足“8的整倍数”这一条件时,ImageLimit(RW_IRAM1) 的后面与 ARM_LIB_HEAP的起始地址之间就会产生一个4字节的气泡

嵌入式

要解决这一问题也很简单,我们可以使用 scatter script 脚本为我们提供的一个专门来进行地址对齐的函数:

AlignExpr(<地址数值>,<对齐要求>)

比如:

AlignExpr(ImageLimit(RW_IRAM1), 8)

就表示对 RW_IRAM1 的终止地址进行 8 字节对齐。借助它的帮助,我们可以修改脚本如下:

#define HEAP_SIZE    
    (RAM1_LIMIT - AlignExpr(ImageLimit(RW_IRAM1), 8))

即:

嵌入式

再编译时,已然没有问题。

 

 

【如何随时随地的了解栈的最大使用情况】


水印法是实现“最大栈用量统计”的最有效方式。其原理也不复杂:

  1. 先用指定的水印常数(比如 0xDEADBEEF)将整个栈填满;
  2. 从栈空间的最初顶部(栈存储空间的终止地址)向下开始搜索之前填充的水印常数——一旦碰到水印,就将当前已经经历过的RAM总量作为栈的最大深度(最大用量);

嵌入式

对于步骤1来说,可以通过前面介绍的 FILL 关键字来完成对栈空间的填充:
ARM_LIB_STACK 0x20000000 ALIGN 8 FILL 0xDEADBEEF EMPTY STACK_SIZE
{
}

然后借助下面的代码完成统计工作:

#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

这里有几点需要说明一下:

  • armlink 为我们提供了通用的语法来获取 execution region 的起始地址、大小和终止地址:

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

这里,BaseLimit被定义成了不定长数组的形式,因此我们可以直接把它们当做常量指针来使用——获取所需的地址。Length被定义成了一个普通的uint32_t型的变量,按照官方文档的要求,虽然很反直觉,但如果要获取它的值——也就是对应execution region的大小,必须要对其进行&操作,并随后强制转化为整形数值。这么说也许有点抽象,不妨对照前面的代码来看:

#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。以表达式 (uintptr_t)&Image$$ARM_LIB_STACK$$Length 获取了 ARM_LIB_STACK 的实际大小。

  • 普通情况下,在变量名中使用 “$” 会在Arm Compiler 6引发警告:

warning: '$' in identifier [-Wdollar-in-identifier-extension]

为了让编译器闭嘴,我们临时对函数 calculate_stack_usage_topdown() 在编译时刻做了屏蔽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__)
#   pragma clang diagnostic pop
#endif

-Wdouble-promotion 则是由printf中的百分比运算引起的,一并屏蔽即可。

在任意时刻,当我们想要知道当前系统的最大栈用量时,可以直接调用函数 calculate_stack_usage_topdown(),比如:
int main(void)
{
    ...
    calculate_stack_usage_topdown();
    ...
}

一个可能的执行结果如下:

嵌入式

自上而下统计栈用量的方法优点是:当栈空间很大而实际栈用量较小时,可以较快的完成统计;缺点是:如果恰好栈里因为任何原因(比如用户定义了一个局部变量,然后恰好给他赋予了我们的水印常数),就会造成统计错误——没能实际获得最大深度。

针对这一问题,我们可以修改搜索策略,从占空间的起始地址(也就是基地址)处向上搜索“非水印常数”——一旦碰到,就可以用已知的栈空间尺寸减去已经经历过的RAM总量作为栈的最大深度(最大用量)。

嵌入式

该方法的优点是:不容易发生误判;缺点是:当栈空间很大而实际栈用量较小时往往较为耗时。对应的代码如下:

#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
 

 

 

【后记】


在这篇文章中,我们介绍了栈和堆在存储器中的常见排布模型,比较了它们的优劣,并提出了一种被称为“两面包夹芝士”的两段式模型。该模型:
  • 可以有效避免堆栈溢出破坏常规变量
  • 溢出发生时可以在大部分芯片中第一时间触发异常——被我们捕捉到

 

后面,我们以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过渡图中与栈相关的障碍。希望对你有所帮助。


审核编辑 :李倩


打开APP阅读更多精彩内容
声明:本文内容及配图由入驻作者撰写或者入驻合作网站授权转载。文章观点仅代表作者本人,不代表电子发烧友网立场。文章及其配图仅供工程师学习之用,如有内容侵权或者其他违规问题,请联系本站处理。 举报投诉

全部0条评论

快来发表一下你的评论吧 !

×
20
完善资料,
赚取积分