本文轉自公眾號,歡迎關注

優(yōu)化導致的問題案例 (qq.com)

• 一.過程
• 二.思考

一.過程

關鍵代碼如下

通過串口驅動接口,注冊串口接收回調函數(shù),uart_rx_callback

該回調函數(shù)中如果收到串口數(shù)據(jù),長度非0,則更新全局變量uart_rx_len

主循環(huán)中再檢查全局變量uart_rx_len,如果大于0說明收到了串口數(shù)據(jù),將收到的數(shù)據(jù)再發(fā)送出去,實現(xiàn)簡單的串口回環(huán)測試。

static int uart_rx_len = 0;
void uart_rx_callback(const void *buffer, uint32_t length)
{
    if(length >0)
    {
        uart_rx_len = length;
    }
}

int main(void)
{
    ......
    debug_uart_init(IOT_UART_PORT_1);
    uint8_t buffer[64];
    iot_uart_register_rx_callback(IOT_UART_PORT_1,buffer,sizeof(buffer),uart_rx_callback);
    while(1)
    {
        if(uart_rx_len > 0)
        {
            iot_uart_write_buffer(IOT_UART_PORT_1,buffer,uart_rx_len);
            uart_rx_len=0;
        }
    }
}

現(xiàn)象是并沒有實現(xiàn)上述回環(huán)測試的功能。

于是進行調試,先確認是否進入了接收處理,

b uart_rx_callback

發(fā)現(xiàn)可以進入該回調函數(shù),說明收到了數(shù)據(jù)。

step單步運行到執(zhí)行完uart_rx_len = length;，再查看該變量的值

(gdb) p uart_rx_len
$2 = 1

也確實收到了一個字節(jié)。

然后繼續(xù)往下看,看如下條件是否進入

if(uart_rx_len  > 0)
        {
            iot_uart_write_buffer(IOT_UART_PORT_1,buffer,uart_rx_len);
            uart_rx_len=0;
        }

b main.c:146 在iot_uart_write_buffer(IOT_UART_PORT_1,buffer,uart_rx_len所在行146行,打斷點。

發(fā)現(xiàn)進不了該斷點。

這里就比較奇怪了,前面uart_rx_len確實是1,了但是這里條件卻進不去,其他地方也沒有寫uart_rx_len的地方。

那么只有繼續(xù)看該處代碼對應的匯編代碼

先在uart_rx_callback前打斷點，串口接收一個字節(jié)觸發(fā)該回調執(zhí)行。再在 if(uart_rx_len > 0)所在的行144行前打斷點,b main.c:144，c運行到該處。

此時看到uart_ex_len的值是1正確的。

(gdb) p uart_rx_len
$2 = 1

layout split打開匯編和C對照窗口。

查看變量uart_rx_len的地址，為0x20300c8

(gdb) p &uart_rx_len
$4 = (int *) 0x20300c8 < uart_rx_len >

(gdb) info reg s1
s1             0x2030000        33751040

S1寄存器的值設置為0x2030000, lui s1,0x2030 lui的u表示up(高20位),加載0x2030到S1的高20位。

lw a2,200(S1)即將S1對應的地址偏移200(0xC8)地址處的值加載到a2寄存器。

正好是獲取0x2030C8(uart_rx_len)的值到A2,

然后再執(zhí)行

blez a2,0x20001ba進行判斷uart_rx_len和0的值比較,判斷是否往下執(zhí)行還是在此死循環(huán)。

初看沒問題,一細看就有端倪了。

假設一開始uart_rx_len=0,

那么后面始終執(zhí)行的是一條語句,blez a2,0x20001ba,a2寄存器的值不再更新了，這就有問題了，內存中0x2030C8(uart_rx_len)的值變了，但是寄存器a2的值不再變化。

這就是編譯器自作主張優(yōu)化,生成的代碼沒有繼續(xù)去從內存0x2030C8(uart_rx_len)處更新值到a2寄存器了。理論上是需要再次執(zhí)行上述lw a2,200(S1)指令的。這就編譯器優(yōu)化導致的問題。

我們修改

static int uart_rx_len = 0;

改為

`static volatile int uart_rx_len = 0;``

再來看匯編代碼。

可以看到如果a5小于0,會跳轉到addi s1,s2,200處執(zhí)行再繼續(xù)lw a5,0(S1)處加載uart_rx_len的值到a5,會不斷從內存處更新值到寄存器。

這就是volatile的作用,加了volatile后編譯器始終,會從內存中更新值到寄存器，而不會自作主張使用寄存器中緩存的值。

默認SCons/riscv_tools.py中是Os優(yōu)化,

CCFLAGS = common_flags + [
        "-Os",
    ]

不加volatile且優(yōu)化改為

-O3,-O2,-O1,-O0分別看一下。

可以看到-O1優(yōu)化編譯就進行了優(yōu)化,后面-O2，-O3就不用看了。

-O0

-O1

二.思考

這里函數(shù)uart_rx_callback寫了變量uart_rx_len

void uart_rx_callback(const void *buffer, uint32_t length)
{
    if(length >0)
    {
        uart_rx_len = length;
    }
}

且uart_rx_callback函數(shù)也作為回調函數(shù)使用了，理論上編譯器應該指導uart_rx_len會被改寫，不應該作此優(yōu)化。

手動調用以下uart_rx_callback

uart_rx_callback(0, 0);
    debug_uart_init(IOT_UART_PORT_1);

還是一樣的優(yōu)化了

看來編譯器還是聰明過頭了。

這里主要是

while(1)后面第一條語句就是判斷uart_rx_len,如果之前還有其他語句,則編譯器可能不會優(yōu)化了。

while(1)

    {

        if(uart_rx_len > 0)

        {

            iot_uart_write_buffer(IOT_UART_PORT_1,buffer,uart_rx_len);

            uart_rx_len=0;

        }

    }

審核編輯：湯梓紅