本文轉(zhuǎn)自公眾號，歡迎關(guān)注
https://mp.weixin.qq.com/s/uzaGLFTDBAn8wyR84yaiIw

0.背景

本文記錄很久之前在一個項目中遇到的”幽靈問題”,結(jié)構(gòu)體讀寫異常，雖然最終結(jié)論很簡單，遇到過類似問題或者了解對應(yīng)知識點的可能一眼就知道了，但是沒遇到過的可能會花費很多時間去定位甚至無從下手。這就是經(jīng)驗的重要性，所以特分享出這篇文章。結(jié)論本身沒有很大的技術(shù)含量，但是中間涉及的思想，態(tài)度，解決問題的思路，過程，如何形成標(biāo)準(zhǔn)，避免類似問題等等確是我們嵌入式開發(fā)中的共性問題。

1.問題回顧

1.1歷史問題1 在不同地方,結(jié)構(gòu)體訪問按照不同對齊方式訪問,開始懷疑keil編譯器的問題。之前還換了keil的不同版本去試都是一樣。

之前can驅(qū)動在改了某版本代碼后突然收不到數(shù)據(jù)，調(diào)試記錄如下:寫和讀時結(jié)構(gòu)體對齊方式不一樣。

mdk未顯式指定結(jié)構(gòu)體對齊方式時,通過.訪問成員變量,可能不同地方對齊方式不一樣。

Mdk版本v5.xx ARM CC編譯器V5.06

寫結(jié)構(gòu)體成員CAN1->sFIFOMailBox[1].RIR 查看對應(yīng)的匯編代碼是STR r0 [SP,#0x0C]

即RIR成員變量偏移地址是0xC，此時采用自然對齊非壓縮方式。寫進(jìn)去的值是0x00 22 E2 F0。

讀結(jié)構(gòu)體成員CAN1->sFIFOMailBox[1].RIR 查看對應(yīng)的匯編代碼是LDR r0 [SP,#0x0A]

即RIR成員變量偏移地址是0xA。與寫時偏移地址不一樣,此時采用了壓縮方式, 讀出來的值是E2 EF A5 A5，偏移了2字節(jié)。查看內(nèi)存，實際內(nèi)存的值是對的,只是結(jié)構(gòu)體訪問時對應(yīng)匯編代碼成員變量的的偏移地址不對,導(dǎo)致解析錯誤,如果按寫入時的偏移0x0C解析讀到的值是0x0022E2EF就是正確的。

解決辦法:暫時不確定是編譯器問題還是配置問題,手動顯式設(shè)置結(jié)構(gòu)體對齊方式,可解決該問題。

1.2歷史問題2 某些結(jié)構(gòu)體增加#pragma pack(1)導(dǎo)致后導(dǎo)致系統(tǒng)異常。

當(dāng)時修改代碼后未復(fù)現(xiàn),沒有記錄現(xiàn)場。

2問題分析過程

查找問題起始點

前面花了差不多一天時間去對比代碼逐漸刪除,最終定位到driver_can.h增加以下代碼

就有問題不加就沒問題

#pragma pack(1)


typedef struct


{


uint16_t rx_in_u16;              /**< 接收緩沖區(qū)寫入指針       */


uint16_t rx_out_u16;             /**< 接收緩沖區(qū)讀出指針       */


uint16_t rx_len_u16;             /**< 接收緩沖區(qū)有效數(shù)據(jù)大小   */


uint16_t tx_in_u16;              /**< 發(fā)送緩沖區(qū)寫入指針       */


uint16_t tx_out_u16;             /**< 發(fā)送緩沖區(qū)讀出指針       */


uint16_t tx_len_u16;             /**< 發(fā)送緩沖區(qū)有效數(shù)據(jù)大小   */


uint16_t rxbuf_len_u16;          /**< 接收緩沖區(qū)大小           */   


uint16_t txbuf_len_u16;          /**< 發(fā)送緩沖區(qū)大小           */


driver_can_data_t *rx_buf_pt;    /**< 接收緩沖區(qū)               */


driver_can_data_t *tx_buf_pt;    /**< 發(fā)送緩沖區(qū)               */


}driver_can_t;

進(jìn)一步驗證

找到出現(xiàn)問題的代碼后就一步步跟蹤

在頭文件中driver_can.h中定義了

在osapi.c中 include “driver_can.h”

導(dǎo)致以下代碼 綠色語句執(zhí)行后出錯。

在osapi.c中 不包含 driver_can.h

上述現(xiàn)象無

調(diào)試分析

用仿真器跟蹤調(diào)試對比有問題和無問題的代碼執(zhí)行時的環(huán)境(變量地址 變量值等)

先包含driver.h 有問題時情況如下:

Osapi.c中如下代碼執(zhí)行

可以看出進(jìn)入函數(shù)uxTaskGetSystemState執(zhí)行前pxTaskStatusArray的eCurrentState和uxCurrentPriority只相差1,說明是pack(1)模式

進(jìn)入函數(shù)uxTaskGetSystemStat后(在task.c中) 看到紅色部分變了,pxTaskStatusArray的eCurrentState和uxCurrentPriority相差4,說明是非pack(1)模式

在后面繼續(xù)給uxCurrentPriority等成員賦值時實際上溢出了,因為傳入pxTaskStatusArray的是復(fù)函數(shù)malloc出來的,所以這里溢出將導(dǎo)致malloc的鏈表關(guān)系破壞導(dǎo)致整個堆環(huán)境破壞,后面問題會蔓延最終導(dǎo)致災(zāi)難性錯誤。

如果上面的pxTaskStatusArray不是malloc出來的而是棧中的臨時變量則會導(dǎo)致棧破壞，最終問題也可能蔓延導(dǎo)災(zāi)難性的錯誤。

而不包含driver.h時

進(jìn)入函數(shù)uxTaskGetSystemState前

進(jìn)入函數(shù)后 沒有變

最終原因

從上可以看出,因為pxTaskStatusArray對應(yīng)結(jié)構(gòu)體是沒有TaskStatus_t顯示指定對齊模式的,

Osapi包含了driver.h的#pragma pack(1)所以osapi整個文件中沒有顯示指定的對齊模式的結(jié)構(gòu)體都按照pack(1)對齊,而task.c中按照默認(rèn)對齊方式(4字節(jié)),所以導(dǎo)致錯誤。

實際上這里是#pragma pack(1)的用法錯誤 正確用法見《總結(jié)》

上述分析過程在keil中也是一樣的,所以之前懷疑的keil編譯有問題是錯誤的,跟編譯器沒有關(guān)系,是pack(1)指令使用錯誤導(dǎo)致。

3.問題回顧

回顧問題一

為什么不同地方結(jié)構(gòu)體訪問不同?

是因為當(dāng)時有些地方的頭文件中增加了#pragma pack(1),有些c文件包含了該頭文件,有寫c文件沒有包含該文件。在包含了該頭文件的c文件中所有沒有顯示指定對齊模式的結(jié)構(gòu)將會按照pack(1)模式,沒有包含該頭文件的c文件中則會按照編譯器默認(rèn)的對齊模式。所以導(dǎo)致不同c文件對齊模式不一樣,關(guān)鍵是看有包含的頭文件中有#pragma pack(1)

為什么對結(jié)構(gòu)體顯示的指定對齊模式后就沒問題?

#pragma pack(1)的含義是: c文件#pragma pack(1)指令后所有沒有顯示指定對齊模式的結(jié)構(gòu)體都會按照pack(1)對齊。

對于顯示指定對齊模式的結(jié)構(gòu)體按照指定對齊模式,所以顯示指定后不受#pragma pack(1)影響

回顧問題二

為什么不知何故加了些代碼就好了?

因為有問題的c代碼中沒有包含有#pragma pack(1)的頭文件,或者結(jié)構(gòu)體顯示的增加了對齊模式。

總結(jié)

結(jié)構(gòu)體對齊方式的指定有兩種,推薦使用第一種

l第一種: 直接對結(jié)構(gòu)體顯式定義對齊模式 這種方式一般使用于頭文件申明時

對于支持gcc屬性擴展的編譯器(IAR KEIL新版本都支持) 使用

例如

typedef struct __attribute__ ((__packed__)) loop_to_channel


{


uint8_t loop;


gpio_ch_e ch;


} loop_to_channel_t;


對于IAR還可以使用__packed


/**


* struct driver_can_status_t


* CAN狀態(tài)結(jié)構(gòu)體.


*/


typedef __packed struct


{


uint8_t send_err;              /**< 發(fā)送錯誤幀計數(shù)     */


uint8_t rcv_err;               /**< 接收錯誤幀計數(shù)     */


uint32_t send_frames;          /**< 發(fā)送幀數(shù)           */


uint32_t rcv_frames;           /**< 接受幀數(shù)           */


uint32_t esr;                  /**< 狀態(tài)寄存器         */


}driver_can_status_t;

l第二種: #pragma pack(1) 這種方式一般使用于c文件中對本文件設(shè)置后所有地方生效

這種方式一定要注意恢復(fù)設(shè)置

正確示例

#pragma pack(push)


#pragma pack(1)


typedef struct


{


uint16_t rx_in_u16;              /**< 接收緩沖區(qū)寫入指針       */


uint16_t rx_out_u16;             /**< 接收緩沖區(qū)讀出指針       */


uint16_t rx_len_u16;             /**< 接收緩沖區(qū)有效數(shù)據(jù)大小   */


uint16_t tx_in_u16;              /**< 發(fā)送緩沖區(qū)寫入指針       */


uint16_t tx_out_u16;             /**< 發(fā)送緩沖區(qū)讀出指針       */


uint16_t tx_len_u16;             /**< 發(fā)送緩沖區(qū)有效數(shù)據(jù)大小   */


uint16_t rxbuf_len_u16;          /**< 接收緩沖區(qū)大小           */   


uint16_t txbuf_len_u16;          /**< 發(fā)送緩沖區(qū)大小           */


driver_can_data_t *rx_buf_pt;    /**< 接收緩沖區(qū)               */


driver_can_data_t *tx_buf_pt;    /**< 發(fā)送緩沖區(qū)               */


}driver_can_t;


#pragma pack(pop)

錯誤示例

#pragma pack(1)


typedef struct


{


uint16_t rx_in_u16;              /**< 接收緩沖區(qū)寫入指針       */


uint16_t rx_out_u16;             /**< 接收緩沖區(qū)讀出指針       */


uint16_t rx_len_u16;             /**< 接收緩沖區(qū)有效數(shù)據(jù)大小   */


uint16_t tx_in_u16;              /**< 發(fā)送緩沖區(qū)寫入指針       */


uint16_t tx_out_u16;             /**< 發(fā)送緩沖區(qū)讀出指針       */


uint16_t tx_len_u16;             /**< 發(fā)送緩沖區(qū)有效數(shù)據(jù)大小   */


uint16_t rxbuf_len_u16;          /**< 接收緩沖區(qū)大小           */   


uint16_t txbuf_len_u16;          /**< 發(fā)送緩沖區(qū)大小           */


driver_can_data_t *rx_buf_pt;    /**< 接收緩沖區(qū)               */


driver_can_data_t *tx_buf_pt;    /**< 發(fā)送緩沖區(qū)               */


}driver_can_t;

審核編輯：湯梓紅