Свързването със статична библиотека не е еквивалентно на свързването с нейните обекти

Резюме:

Проблемът беше, че не всички обекти от статичната библиотека бяха включени в изображението на фърмуера. Това се решава чрез обграждане на статичната библиотека с флаговете за свързване --whole-archive и --no-whole-archive:

 $(CC) $(CFLAGS) $(LDFLAGS) -o $@ $(APPOBJECTS) -Wl,--whole-archive Library/libtest.a -Wl,--no-whole-archive

Проблемът възниква, защото ако линкерът включва библиотечен обект със слаби дефиниции на символи, той счита тези символи за дефинирани и вече не търси техните (силни) дефиниции. Следователно обектът със силни дефиниции може или не може да бъде включен, в зависимост от реда на търсене и какви други символи дефинира.

Път на решение:

Използвайки arm-none-eabi-gdb за отстраняване на грешки, изглежда, че деактивираното WWDG прекъсване се случва и извиква Default_Handler. Това се оказа червена херинга... което се е случвало достатъчно често, за да ме доведе до отговора чрез "STM32 WWDG прекъсва задействане, когато не е конфигуриран" публикация на stackoverflow.

След като прочетох тази публикация и научих, че отчитането на името на gdb функцията често е неточно за функции, които споделят един и същ адрес на паметта, проверих генерирания .map файл за дефектно изображение на фърмуера и потвърдих, че WWDG_IRQHandler се намира на същия адрес в паметта като повечето на IRQHandlers включително IRQHandlers за прекъсвания, които са дефинирани и използвани от системата (напр. някои прекъсвания на таймера).

Освен това, всички прекъсвания, дефинирани в обекта stm32f4xx_it.o (който дефинира IRQHandlers за прекъсвания, използвани от системата, и който е включен в статичната библиотека), сочат към адреса на паметта на Default_Handler и съответния IRQHandler символите бяха посочени като предоставени от startup_stm32f407xx.o.

След това проверих кои обектни файлове всъщност са свързани в изображението на фърмуера (perl -n -e '/libtest\.a\((.*?)\)/ && print "$1\n"' app.map | sort -u) и открих, че само подмножество от обекти са свързани.

Допълнителна проверка на startup_stm32f407xx.s показа, че той дефинира много слаби символи, напр.

.weak TIM2_IRQHandler

По време на процеса на свързване на статична библиотека, линкерът търси в библиотеката недефинирани символи и включва първия обект, който намери, за да дефинира тези символи. След това премахва символа от недефинирания списък, както и всички други недефинирани символи, които са дефинирани от включения обект.

Моето предположение за случилото се е, че линкерът е намерил иначе недефиниран символ в startup_stm32f407xx.o и е включил обекта. Той счита, че всички символи на IRQHandler са дефинирани от слабите дефиниции в тях. Обектът stm32f4xx_it.o никога не е бил включен, тъй като не е дефинирал никакви недефинирани символи. Това се случи няколко пъти, с множество различни обектни файлове; понякога бяха включени силните символи, понякога слабите символи бяха включени, в зависимост от това кой обект е претърсен първи. Интересно (но не е изненадващо) е, че ако слабата дефиниция бъде премахната, обектът, съдържащ силната дефиниция, се включва и всички силни дефиниции от този файл (правилно) заместват вече включените слаби дефиниции.

След като реших проблема, не съм сигурен накъде да отида от тук. Това грешка в линкер ли е?

Ще получите по-добър отговор, ако можете да обясните какво всъщност означава „двоичният файл не работи“.

Получавате ли двоичен файл, който вашите инструменти за програмиране изобщо не зареждат в чипа?

Ако е така, погледнете внимателно изхода на линкера в командния ред.

Произвеждате ли нещо, което можете да заредите в чипа и не виждате очакваното поведение?

Ако е така, използвайте хардуерен дебъгер. Преминавайте през кода, докато нещо се счупи, или го оставете да работи, след което го спрете и вижте къде сте попаднали.

Вероятно просто разкривате грешка, която винаги е била в кода, като пренареждате къде отива всичко в паметта. Препълване на масиви, лоши дереференции на указатели и неинициализирани променливи са типични виновници. Включването на -Wextra и -Wall може да помогне за разкриването на тези неща.

Друга мисъл: Уверете се, че LDSCRIPT има правилните размери на флаш и RAM за действителния номер на частта (т.е. не е за различна част от семейството).

В момента също работя с този MCU. Въпреки това избягвам ST "стандартната" библиотека по основателни причини.

Изглежда, че пазачът е активиран по време на стартиране и изтича скоро (прекъсването е ранно предупреждение. Това може да се дължи на вариации в поведението по време на изпълнение. Това може много да варира в зависимост от връзката поради батути, създадени от линкера и/или Tink-Time оптимизация (LTO) и вграждане от компилатора и други оптимизации.

Дадените размери изглеждат извън границите за нормална вариация с идентични опции за компилиране/връзка. Но те са много възможни за -Os срещу -O3 и LTO/без LTO (докато за последното полученият размер на кода може да бъде много по-голям или по-малък, в зависимост от -O). Освен това забелязах, че някои версии на gcc/ld имат проблеми с LTO и целият код трябва да бъде компилиран и свързан(!) със същите опции. Също така проверете използвания ABI и дали той съответства на използваните (C- и gcc-libs.

Добро начало би било грубо стъпково стартиране от нулиране с точка за наблюдение на WWDG->CR. Също така проверете EWI-бита; това всъщност би позволило прекъсването.