又是編譯器的鍋？全局變量怎么就從棧里取數(shù)據(jù)了？！

來源：公眾號(hào)【魚鷹談單片機(jī)】，ID ：emOsprey

一個(gè)學(xué)員項(xiàng)目上需要完成app升級(jí)功能，但是跳轉(zhuǎn)后直接 hardfault，項(xiàng)目緊急，只能找上魚鷹加急處理（課程福利）。

這種問題我都是比較自信的，M0+ 內(nèi)核，感覺問題不大，只是沒想到學(xué)員公司保密性比較強(qiáng)，不能遠(yuǎn)程控制電腦，只能微信視頻進(jìn)行指導(dǎo)調(diào)試，折騰許久，才最終定位跳轉(zhuǎn)地址出現(xiàn)問題。

static ?uint32_t jmp_app;

static uint32_t jmp_stack;

jmp_app = xx

jmp_stack = xxx

關(guān)閉中斷

__ISB();

__DMB();

設(shè)置中斷向量表

設(shè)置 msp 和 psp 棧

((void (*)(void))jmp_app)();

代碼類似如上，但是很奇怪的是，執(zhí)行最后一條代碼時(shí)，會(huì)從棧中取jmp_app的值（通過匯編分析），導(dǎo)致最終跳轉(zhuǎn)地址異常而hardfault，這個(gè)變量明明是靜態(tài)全局變量，而且同樣的代碼在stm32沒有問題。

全局變量數(shù)據(jù)從棧里面取，怎么都不符合常理，要么優(yōu)化后從寄存器取，要么從ram中取才對，沒聽說過要通過棧取數(shù)據(jù)（難道是前面設(shè)置棧的操作導(dǎo)致？）。

這個(gè)問題最終由學(xué)員發(fā)現(xiàn)是編譯器的鍋，用-O0 compiler6可以穩(wěn)定出錯(cuò)，compile5沒問題，之前看一篇硬漢的文章說ac6在O0處理復(fù)雜宏時(shí)會(huì)產(chǎn)生大量的棧，O1沒問題，才知道編譯器也不可盡信，匯編也需要懂，否則出現(xiàn)類似問題根本無法解決，不知道各位道友是否有遇到類似問題。