Сравниваю размещение переменных проекта при использовании gcc-arm-none-eabi-8-2019-q3-update и gcc-arm-none-eabi-10-2020-q4-major, при абсолютно идентичных ключах компиляции.
Напомню код
netif.c
struct netif *netif_list; struct netif *netif_default; static u8_t netif_num;
pbuf.c
volatile u8_t pbuf_free_ooseq_pending;
Про GCC v10 вы уже знаете:
.bss 0x00000000001820a8 0x9 objs/debug/./lwIP/1.4.1/lwip/src/core/netif.o 0x00000000001820a8 netif_list 0x00000000001820ac netif_default .bss 0x00000000001820b1 0x1 objs/debug/./lwIP/1.4.1/lwip/src/core/pbuf.o 0x00000000001820b1 pbuf_free_ooseq_pending
А вот GCC v8 удивил. Я ожидал идентичный результат: размещение переменной pbuf_free_ooseq_penging в секции .bss по невыровненному адресу. А оказалось вот что.
.bss 0x000000000007e047 0x1 objs/debug/./lwIP/1.4.1/lwip/src/core/netif.o
...
COMMON 0x00000000001e15bc 0x8 objs/debug/./lwIP/1.4.1/lwip/src/core/netif.o 0x00000000001e15bc netif_list 0x00000000001e15c0 netif_default COMMON 0x00000000001e15c4 0x1 objs/debug/./lwIP/1.4.1/lwip/src/core/pbuf.o 0x00000000001e15c4 pbuf_free_ooseq_pending
При идентичных ключах, размещение происходит в секции COMMON, и адрес выравнивается по границе слова.
В GCC v10 секция COMMON вообще полностью пустая.
Ещё удивительно (GCC v10): просто меняя функции местами внутри модуля netif.c (перемещая с одних строк на другие), меняется адрес размещения pbuf_free_ooseq_pending, почти всегда адрес выровненный.
Неудивительно, что OpenNuvoton bare-metal не глючит: там не используют gcc v10.
Приму локальное решение: отказаться от GCC v10 в пользу GCC v8. Времени на разборки нет. Появится, начну разборки. Кстати, последняя сегодня выкачанная версия gcc 10.3-2021.10 ведёт так же.
-
- Спасибо. Респект за проработку вопроса. - Cкpипaч(01.07.2022 12:09)