【GCC编译优化系列】究竟什么样的代码会导致函数调用的栈溢出呢？
一段看似铁定栈溢出的函数代码，它一定会溢出吗？
1 问题现场事情是这样的，最近我们在考虑招收一批新鲜血液，首次尝试大规模招收应届生和大三实习生。也是受领导所托，让我出几道笔试题，刚好我最近在项目中遇到一个栈溢出的问题，于是简单写了这么一段函数：
复制__attribute__ ((noinline)) int test_handler(void) { uint8_t msg[16] = {0}; memcpy(msg, “hello6666666666666666666666666666”, 100); return msg[0]; }**笔试的题目是：**请问这段代码有没有问题？如果有，请指出其问题所在，并尽可能地阐述其风险所在。
2 简单分析**朋友，要是你看到这样一道笔试题，你可能会第一时间大笑起来，这不就是一道典型的 函数栈溢出 的代码场景题吗？教科书都偶讲过啊！
但是，真的仅仅是这样吗？
**我们先来简单分析一下这个函数代码：
1）函数先定义了一个16字节长度的msg数组；
**2）仅接着使用memcpy对msg数组进行操作赋值；从字符串 “hello6666666666666666666666666666” 中拷贝100个字节到msg数组中；
**3）由于msg数组仅有16字节的长度，且这部分内存是位于栈中，而第2）中拷贝的长度却是100字节，大于了16个字节，这样msg数组就不够空间来存储了，因此触发了很典型的 栈溢出 问题。
以上是很常规的教科书式的分析，如果我在笔试场上遇到这道题，我肯定也是这么描述。
但是这些年，随着我对编译优化有了更多的认知后，我开始有不同的看法。
3 深入分析本文先不考虑其他编译器的情况，仅以ARM-GCC编译器最为讨论，准确地说，编译器版本是：
复制arm-none-eabi-gcc -v gcc version 9.2.1 20191025 (release) [ARM/arm-9-branch revision 277599] (GNU Tools for Arm Embedded Processors 9-2019-q4-major)根据问题代码，下面按两种情况深入分析：
3.1 假如不考虑编译优化的情况
**在GCC编译器中，如果想让代码编译不执行任何优化，可以考虑将CFLAGS中加入 -O0 这个优化级别。
同时，上一小节中，我们仅仅是从C代码（高级语言代码）的角度分析，得出栈溢出的结论，而我们如果想知道这段代码真正在经过编译器编译后，得到什么样的执行代码，还得看最后生成的汇编代码才行。
**于是，我在配置优化级别为 O0 后，得到以下汇编代码，它对应的就是test_handler函数。
复制.LC48: .ascii “hello6666666666666666666666666666\\\\000” .section .text.test_handler,“ax”,%progbits .align 1 .global test_handler .syntax unified .code 16 .thumb_func .fpu softvfp .type test_handler, %function test_handler: .LFB36: .loc 1 299 1 .cfi_startproc @ args = 0, pretend = 0, frame = 16 @ frame_needed = 1, uses_anonymous_args = 0 push {r7, lr} .cfi_def_cfa_offset 8 .cfi_offset 7, –8 .cfi_offset 14, –4 sub sp, sp, #16 //定义msg数组，长度为16个字节 .cfi_def_cfa_offset 24 add r7, sp, #0 .cfi_def_cfa_register 7 .loc 1 300 13 movs r3, r7 movs r2, #0 str r2, [r3] adds r3, r3, #4 movs r2, #12 movs r1, #0 movs r0, r3 bl memset //调用memset函数对msg数组进行清0操作，因为我定义msg数组时，加了 {0} 做初始化 .loc 1 302 5 ldr r1, .L77 movs r3, r7 movs r2, #100 movs r0, r3 bl memcpy //调用memcpy函数对msg数组进行拷贝赋值 .loc 1 304 15 movs r3, r7 ldrb r3, [r3] .loc 1 305 1 movs r0, r3 //把msg[0]放到r0寄存器，准备退出函数 mov sp, r7 add sp, sp, #16 @ sp needed pop {r7, pc} //函数退出 .L78: .align 2 .L77: .word .LC48 .cfi_endproc简单分析一下这段汇编代码：
**1）一开始定义了一个字符串，内容是”hello6666666666666666666666666666\\000″，它的标签号是 **.LC48
**2）接下来就是test_handler的定义，它的起始地址标签是 **.LFB36
3）其他的汇编代码，见代码中的注释
从上面的分析可以看出，基本上就是跟我们分析C代码是一致的；也就是说，这种情况下，这个函数发生栈溢出是一定的。
感兴趣的朋友也可以把这段代码集成编译到你的代码工程中，看看会发生什么事。
3.2 如果编译器执行了编译优化
**以上分析只是一种常规的场景，在实际的嵌入式编译中，往往我们采用的是 **Os 级别的优化，在这个级别的优化下，启用了很多编译优化选项，并尽可能地为 缩小镜像的size 而服务，这也是 Os 名称的含义来源。
**我们把优化级别配置成 **Os 后，我们来看下得到的汇编代码是怎么样的：
复制.section .text.test_handler,“ax”,%progbits .align 1 .global test_handler .syntax unified .code 16 .thumb_func .fpu softvfp .type test_handler, %function test_handler: .LFB36: .loc 1 299 1 is_stmt 1 view -0 .cfi_startproc @ args = 0, pretend = 0, frame = 0 @ frame_needed = 0, uses_anonymous_args = 0 @ link register save eliminated. .loc 1 300 5 view .LVU194 .loc 1 302 5 view .LVU195 .loc 1 304 5 view .LVU196 .loc 1 305 1 is_stmt 0 view .LVU197 movs r0, #104 //整数104赋值给r0寄存器，准备函数退出 @ sp needed bx lr //函数退出 .cfi_endproc简单一看，哗，这个汇编代码精简了许多，至少从代码行数上就下降了不少。
细细一看，多了些门道。
1）首先，”hello6666666666666666666666666666\\000″ 字符串没有再被定义了；
2）其次，msg数组也没有被定义了；
3）这段汇编代码，有效的代码其实就只有2句： 复制movs r0, #104 和 复制bx lr
啥意思？就这么简单？
原来的在编译优化级别Os的帮助下，这个函数直接就知道了最后返回的ret，其实就是字符串”hello6666666666666666666666666666\\000″的第一个字符，即h，而这个h字符的ASCII值，正好就是 104（10进制数）。
所以这个函数简单地不能再简单，就变成了类似这样的伪代码：
复制int test_handler(void) { return 104; }**所以，你跟我说，这样的函数代码会发生 **栈溢出 吗？这显然是不会的啊！
**另外一点，也值得注意的是，细心的朋友可能看到我在 **test_handler 函数前加了一个 **attribute ((noinline)) **；这个是GCC的扩展功能，目的就是告诉编译器，这个函数需要帮忙保留，不要变成 内联函数 。
**倘若，我把这个修饰去掉后，会是怎么样呢？显然会把这个函数编译成 ** 内联函数 ，具体的汇编代码是怎么样的，感兴趣的朋友可以自己去实践一下。
4 经验总结这个小小的代码片段，告诉我们的道理就是：
**别总是盯着眼前的 **”苟且“（代码） ，必要的时候，还需要看得更深，看得更远，别被眼前的一切所蒙蔽了； 纸上得来终觉浅，绝知此事要躬行 ；教科书上面的讲解并没有错，但是放到实际的应用场景下，不见得一定会100%争取； **努力提升自己 **汇编、反汇编 的技术能力，关键时候也许你助你一臂之力。 5 更多分享架构师李肯
架构师李肯 （ 全网同名 ），一个专注于嵌入式IoT领域的架构师。有着近10年的嵌入式一线开发经验，深耕IoT领域多年，熟知IoT领域的业务发展，深度掌握IoT领域的相关技术栈，包括但不限于主流RTOS内核的实现及其移植、硬件驱动移植开发、网络通讯协议开发、编译构建原理及其实现、底层汇编及编译原理、编译优化及代码重构、主流IoT云平台的对接、嵌入式IoT系统的架构设计等等。拥有多项IoT领域的发明专利，热衷于技术分享，有多年撰写技术博客的经验积累，连续多月获得RT-Thread官方技术社区原创技术博文优秀奖，荣获CSDN博客专家、CSDN物联网领域优质创作者、2021年度CSDN&RT-Thread技术社区之星、2022年RT-Thread全球技术大会讲师、RT-Thread官方嵌入式开源社区认证专家、RT-Thread 2021年度论坛之星TOP4、华为云云享专家（嵌入式物联网架构设计师）等荣誉。坚信【知识改变命运，技术改变世界】！
审核编辑：汤梓红
