弱符號是指在定義或者聲明一個對象（變量、結構體成員、函數）時，在對象的前面添加?__attribute__((weak))?標志所得到的對象符號。如下所示函數即為一個弱對象符號 void test_weak_attr(void)，或者稱該函數是弱函數屬性的、虛函數。
__attribute__((weak)) void test_weak_attr(void)// 或者使用如下樣式的定義，兩者等效void __attribute__((weak)) test_weak_attr(void){printf("Weak Func!\r\n");}
弱符號的作用與示例
弱符號是相對于強符號而言的，在定義或者聲明變量、函數時，未添加?__attribute__((weak))?標識的就默認為強符號。如下，最普通的函數定義，就是定義了一個強符號 void test_strong_ref(void)：
void test_weak_attr(void){printf("this is a strong func\r\n");}
驅動程序往往需要考慮兼容性，因為要兼任很多廠商的不同型號的設備。若驅動程序中使用強符號定義一些與適配的設備的特性相關的功能，則下次適配其他設備時，該強符號函數可能需要被修改，以兼容新的設備。當適配的設備很多時，頻繁地更改驅動代碼將破壞驅動的可維護性。
弱符號的出現可以很好地解決該問題。弱符號的對象具有可以被重定義的功能（即可以被重載）。下面通過測試說明弱符號這種可被重載的特性。
在 test_weak_attr.c 程序中定義如下弱函數：
// test_weak_attr.c__attribute__((weak)) void test_weak_attr(void){printf("this is a weak func\r\n");}
在 main.c 中定義如下程序：
// main.cvoid test_weak_attr(void){printf("this is a strong func\r\n");}void app_main(void){printf("init done\r\n");test_weak_attr();}
編譯運行該 main.c 程序，得到的結果是什么樣子的呢？
1 | this is a strong func |
將 main.c 中的 void test_weak_attr(void) 函數注釋掉，再重新編譯運行程序得到的結果是：
1 | this is a weak func |
小結：在使用弱符號函數時，我們可以重新定義一個同名的強符號函數來替代它；若沒有重新定義一個強函數來替換它，就使用弱函數的實現。弱函數就好像是一個可以被替換的“默認函數”。
值得一提的是，舊版本的編譯器還可以使用如下方式的定義（僅聲明無效）將一個對象定義為一個弱對象：
1 2 3 4 | __weak void f(void) { //code } |
在 linux 的一些代碼中，__weak 其實就是通過?__attribute__((weak))的重命名，兩者等效。
弱引用是在聲明一個對象時，通過__attribute__ ((weakref())?定義一個符號的引用關系。如下所示即定義 test_weakref() 函數弱引用 test_weak_ref() 函數。
1 | static void test_weakref(void) __attribute__ ((weakref("test_weak_ref"))); |
弱引用是相對于強引用而言的。未通過?__attribute__ ((weakref())?的符號和實現代碼之間的關系是強引用。如下即為一個強引用函數。它直接給出了 函數 test_strong_ref(void)?的實現。
1 2 3 4 | static void test_strong_ref(void) { ????printf("this is a strong ref\r\n"); } |
在編譯程序的時候，我們可以直接使用 test_strong_ref(void)?而不必擔心編譯不通過。如果，我沒有時間去實現 test_strong_ref(void) ，還想在程序里先使用該函數那該如何呢？（是的，就是想白嫖，不想實現，還想先在程序里使用這個函數）。
這個時候弱引用就派上用場了。可以先將該函數定義為弱引用插入到代碼中，待后期有時間再慢慢優(yōu)化代碼實現這個函數完整的功能。下面結合測試進行說明。
static void test_weakref(void) __attribute__ ((weakref("test_weak_ref")));void app_main(void){printf("init done\r\n");if (test_weakref) {test_weakref();} else {printf("There is no weakref\r\n");}}
測試結果：
There is no weakref
void test_weak_ref(void){printf("this is a weak ref\n");}static void test_weakref(void) __attribute__ ((weakref("test_weak_ref")));void app_main(void){printf("init done\r\n");if (test_weakref) {test_weakref();} else {printf("There is no weakref\r\n");}}
測試結果：
this is a weak ref
小結：強引用，在未定義該強引用的實現時，編譯會報錯誤：未定義的引用。弱引用允許定義一個未實現（未實例化）的對象，這在編譯的時候會將該對象處理成 NULL，編譯器并不會報錯。通過使用弱引用可以實現后期優(yōu)化代碼的功能。而避免改動使用該函數的地方。使用弱函數可以實現類似“鉤子（hook）"函數的功能。
實際上，包括C、python、go 編程語言在內的很多語言 都有類似用法，本篇文章敘述的方法同樣適用于這些語言的相關開發(fā)。
注意：弱引用僅在靜態(tài)編譯中有效，動態(tài)鏈接中可能無效。
弱符號、弱引用都是增強程序的可維護性的方法。弱符號通過可以被重定義的特性，實現可以被替換實現。弱引用通過可以暫時使用一個未定義的函數的功能，實現允許后期再實現該函數具體功能，而不必擔心編譯不通過。
為了方便理解，我們先預設一個應用場景：
我們編寫了一個模擬IIC的驅動，希望它能夠在不同的的平臺運行，目標的平臺就設為 stm32 標準庫，stm32 HAL 庫，stm32 LL 庫，和 RT-Thread Driver 驅動庫。
或許讀者有疑惑，為什么同樣是 stm32 ，卻分成三個平臺呢？這是因為從跨平臺軟件編寫者的角度看，只要調用的庫的 API 不一致，就和換一個不同的平臺沒有什么本質的差別，如果在代碼中寫死了 API 的調用，即使是同一個平臺，仍然像多平臺一樣不能運行。
由此可以看出，跨平臺的困難所在，也不是由硬件平臺所導致的，而是由代碼所依賴的 API 的不同導致的。同一個平臺，如果依賴的 API 不同，代碼就不能跨平臺，同樣地，不同的平臺，如果依賴的 API 相同，也可以跨平臺。
所以歸根結底，是代碼所依賴的 API 出現了不同，所以下文中所說的“平臺”，實際上對應的是一套 API 。
我們繼續(xù)說這個模擬 IIC 的驅動，模擬 IIC 驅動是使用 GPIO 的反轉來模擬 IIC 協議，所以依賴了平臺的 GPIO API，如果把調用 GPIO 的部分寫死，那么換一個平臺，就肯定不能在多個平臺上運行。
下面我們開始討論在多平臺運行的解決方案。
我們先從最樸素簡單的解決方案開始，然后逐步迭代到弱函數的方案，這樣有兩方面好處：
一是從簡單的方案開始，循序漸進地介紹，可以降低閱讀門檻。
二是可以帶讀者親歷一遍方案的演進過程，以及演進動因。
和給直接給結果相比，注重過程和動因更能夠還原技術決策的真實過程。因為任何技術都是從簡單樸素逐步演進而來的，如果直接給出最后的結果，會產生理解的斷層，即使記住了幾種技術的優(yōu)劣，在新的場景中，面對更加多樣化的實際問題也會難免乏力。
先從最樸素的方案講起。
方案一、手動控制添加編譯的 .c 文件
樸素的方案有很多，比如就是多搞幾個版本的 .c 文件，比如SIMU_IIC_STM32_HAL.c ，SIMU_IIC_STM32_LL.c, SIMU_IIC_RTT.c 需要哪個就添加哪個進去編譯不就完了嘛！
這種樸素的方案雖然看起來簡單，但是，這幾個文件中包含有共用的邏輯，例如模擬 IIC 的協議的實現，如何將 8bit 的數據依次發(fā)送，等等。
這些共用的邏輯，相當于在每個文件中都復制了一份，一旦修改到共用的邏輯，就要手動同步每個文件，這會導致代碼冗余和維護難度的急劇增加，很容易出現人為失誤。如果需要添加更多的平臺支持，就需要再次復制修改代碼。
另一個問題是，使用不同的編譯工具鏈，添加編譯文件的方式并不一樣，例如，Visual Studio 和 MDK keil 通常是手動添加，而 CMake 通常直接添加目錄或者通過文件后綴進行搜索。用戶在使用不同的編譯工具時，需要針對編譯工具來分別處理，這也增加了維護的成本。
因此，我們需要尋找更加優(yōu)雅的解決方案。
方案一中最核心的問題，是沒有分離共用的邏輯，和各個平臺的適配接口。
在通常的命名慣例中，共用的邏輯稱為 Common，而各個平臺的適配接口稱為 Port。
在接下來的方案中，我們就會引入 Common 和 Port 分離的設計思想，Common 和 Port 的分離，使得對共用邏輯的修改和增強直接 “分發(fā)” 到了各個的 Port 中，而增添新的平臺，不需要對 Common 做任何修改。
方案二、條件編譯
一種更加優(yōu)雅的解決方案是使用條件編譯。條件編譯是一種編譯時根據條件選擇編譯代碼的技術，可以通過編譯器提供的宏定義和預處理指令來實現。
在我們的模擬 IIC 驅動中，可以直接編寫 Common 部分，然后 Common 部分通過條件編譯，可以根據平臺的不同選擇不同的 GPIO Port API。
例如，在 STM32 標準庫中，可以使用 GPIO_SetPinMode 和 GPIO_WritePin 接口來模擬 IIC 協議，而在 STM32 HAL 庫中，可以使用 HAL_GPIO_WritePin 和 HAL_GPIO_ReadPin 接口來模擬 IIC 協議。因此，在代碼中可以使用如下的條件編譯方式：
/* STM32 Standard Peripheral Library */GPIO_SetPinMode(SDA_PORT, SDA_PIN, GPIO_MODE_OUTPUT_PP);GPIO_SetPinMode(SCL_PORT, SCL_PIN, GPIO_MODE_OUTPUT_PP);.../* STM32 HAL Library */HAL_GPIO_WritePin(SDA_PORT, SDA_PIN, GPIO_PIN_SET);HAL_GPIO_WritePin(SCL_PORT, SCL_PIN, GPIO_PIN_SET);.../* STM32 LL Library */LL_GPIO_SetOutputPin(SDA_PORT, SDA_PIN);LL_GPIO_SetOutputPin(SCL_PORT, SCL_PIN);.../* RT-Thread Driver */rt_pin_mode(SDA_PIN, PIN_MODE_OUTPUT);rt_pin_mode(SCL_PIN, PIN_MODE_OUTPUT);...
這樣，在編譯代碼時，我們可以通過宏定義來選擇編譯使用哪個平臺的代碼，
從而實現跨平臺運行。
然而，這種條件編譯方式還是有一些問題，如果我們需要添加新的平臺支持，就需要添加新的宏定義和條件編譯，而且需要修改模塊的源碼。
方案三 函數指針
我們可以進一步分離 Common 和 Port，將其放在不同的 .c 文件中，Common 通過函數調用的方式來訪問 Port 提供的接口，這樣可以更加靈活和方便地添加新的平臺支持。
具體實現可以通過在 Common 中定義一些函數指針類型來實現。
例如，我們可以定義一個名為 IICOps 的結構體，其中包含了一些指向函數的指針，這些函數實現了具體的 IIC 操作。
在 Port 中，我們實現這些函數，并將其指針傳遞給 Common 中的 IICOps 結構體。
這樣，在 Common 中就可以通過調用這些函數指針來訪問 Port 提供的接口了。
這種方案的好處是，添加新的平臺支持時，只需要實現相應的 Port 函數，并將其指針傳遞給 Common 中的結構體即可，不需要修改 Common 的源碼。
同時，由于 Common 和 Port 分離，不同平臺的適配代碼可以相互獨立，修改一方不會影響到另一方，從而減少了代碼冗余和維護難度。
但是，使用函數指針有兩個主要的缺點，一是函數指針本身需要占據內存，增加了內存的開銷，二是函數指針需要在初始化時進行加載。
具體來說，函數指針的內存開銷相對于代碼本身并不大，通常可以忽略不計，但在嵌入式系統中，資源有限，內存開銷需要更加注意。
而函數指針的初始化需要在程序啟動時進行，這也會對程序的啟動時間產生一定的影響。此外，函數指針的使用可能會導致一定的運行時開銷，需要在程序性能和資源利用方面做出權衡。
另外，函數指針的使用需要程序員有一定的技術水平和經驗，需要合理地進行函數指針的定義、傳遞和調用等操作，避免出現潛在的錯誤和安全問題。
總的來說，函數指針是一種比較靈活和方便的方式，可以幫助我們實現代碼的跨平臺支持，但需要在實際應用中仔細考慮其使用場景和影響，做出合理的決策。
方案四、Common 中聲明，Prot 中實現
在這種方案中，我們仍然將 Common 和 Port 分離，但是我們不再使用函數指針來訪問 Port 中的接口，而是將其定義為 extern 聲明，由 Port 來實現具體的函數。
具體實現可以通過在 Common 中定義一些 extern 聲明的函數，這些函數實現了具體的 IIC 操作，但是并不在 Common 中實現具體的代碼邏輯，而是在 Port 中實現。
在 Port 中，我們實現這些函數，并將其聲明為 extern，然后在編譯時鏈接到 Common 中。
這樣，在 Common 中就可以通過調用這些函數來訪問 Port 提供的接口了。
這種方案的好處是，添加新的平臺支持時，只需要實現相應的 Port 函數，并在編譯時鏈接到 Common 中即可，不需要修改 Common 的源碼。
這樣 Port 的實現函數的掛載就提前到了編譯階段，避免了運行時掛載函數指針的復雜性和容易出錯問題。以及避免了函數指針的內存占用。
但是，和 IIC 的例子不同的是，在一些更實際的項目中，隨著軟件復雜度的提升， Common 中使用的 Port 函數數量會快速膨脹，這時，每個 Port 函數都必須要實現，即使這個功能非常的冷門，這樣 Common 中每增加一個 Port 的依賴，都要求所有的 Port 進行及時的跟進，否則整個項目都無法編譯通過。
接下來，就要有請 weak （弱函數）機制出馬了
但方案四的缺點在于，在一些更實際的項目中，隨著軟件復雜度的提升，Common 中使用的 Port 函數數量會快速膨脹，這時，每個 Port 函數都必須要實現，即使這個功能非常的冷門，這樣 Common 中每增加一個 Port 的依賴，都要求所有的 Port 進行及時的跟進，否則整個項目都無法編譯通過。
方案五 弱函數
為了解決這個問題，可以使用 weak （弱函數）機制，將所有的 Port 函數都定義為 weak 函數。
weak 函數是一種特殊的函數類型，帶 weak 的函數和不帶 weak 的函數可以同時存在，如果有不帶 weak 的函數，就會優(yōu)先鏈接不帶 weak 的實現，如果沒有找到不帶 weak 的實現函數，就會使用 weak 函數作為默認的實現。
即，在使用弱函數時，如果找到多個實現，鏈接器會選擇優(yōu)先級最高的實現。
在 C 語言中，可以使用 attribute((weak)) 來聲明一個函數為弱函數。例如：
attribute((weak)) void port_func(){// 默認實現}attribute((weak)) void port_func()
而在 Port 中，只需要實現需要的函數即可，如果某些函數不需要實現，可以不用管它，因為在鏈接時會使用 Common 中的默認實現。
這樣在編譯時如果沒有找到相應的實現函數，就會使用默認的實現，而不會導致編譯錯誤。
而在 Port 中，只需要實現需要的函數即可，如果某些函數不需要實現，可以不用管它，因為在編譯時會使用 Common 中的默認實現。
這樣，在添加新的平臺支持時，只需要實現需要的函數，而不用實現所有的函數，大大簡化了開發(fā)的難度和工作量。同時，也避免了函數指針的內存占用和運行時掛載函數指針的復雜性和容易出錯問題。
弱函數的多編譯器支持
在不同的平臺上， weak 的聲明方法也會有所不同，因此需要自己定義一個 weak 聲明，例如 MY_WEAK，來支持不同的平臺：
/* Compiler */*//* default MY_WEAK */
可以看到，在不同的編譯器下，weak 有不同的寫法，上面的這些定義包含了對 armcc5、 armclang、IAR、GCC 的支持。
然而，弱函數的方案在一些平臺有一些明顯的缺陷，例如，MSVC編譯器是微軟公司開發(fā)的C/C++編譯器，在Windows操作系統下被廣泛使用。與GCC和Clang等主流編譯器相比，MSVC對于弱函數的支持不太完善。
MSVC 中，可以通過使用#pragma weak來聲明弱函數，但是這個特性只能在 x86 和 x64 平臺下使用，而在 ARM 平臺下是不支持的。
此外，在一些版本的MSVC編譯器中，#pragma weak 的功能也存在一些限制和bug，所以一般在 MSVC 中直接取消 weak 還會更實際一些。
用弱函數對 Port 進行分類
weak 的引入使得我們的 Port 可以根據實際的需求進行劃分，而不是一股腦地必須實現所有的 Port 函數。
引入了 weak 之后，我們就有條件將 Port 劃分為以下的幾種：
1.核心且無默認實現的 Port
這屬于必須實現的 Port，缺乏這個 Port，模塊的核心功能就運行不起來。例如模擬 IIC中對 IO 的操作 Port 函數，這種 Port 用不用 weak 的區(qū)別不大，屬于最硬的骨頭，在設計軟件時應當注意盡可能地減少這種 Port。
在設計軟件時，可以直接取消這類 Port 的弱定義，讓編譯器在編譯時就拋出錯誤。既然缺少了這類 Port 系統的核心功能就無法工作，那么編譯通過了也沒有什么意義。
2. 核心且有默認實現的 Port
這類 Port 可以直接定義一個默認實現，在大多數情況下，用戶就可以不用管這個 Port 了，而在有定制需求的場合下，又可以靈活地定制。
例如弱定義一個 port_printf 用來支持跨平臺軟件的打印輸出，默認是直接使用平臺的 vprintf，對于大多數的用戶來說，只需要打印到平臺自帶的 printf 即可，因此對于大多數用戶來說，這個 Port 不用實現，就能正常使用系統了。
attribute((weak)) void port_printf(char* fmt, ...) {va_list args;va_start(args, fmt);vprintf(fmt, args);va_end(args);}
而有定制需求的用戶可以通過自己重寫 port_printf() 來打印到其他的地方（比如輸出到 log，或者輸出到其他串口）。
在 printf 的例子中，我們默認了 printf 是所有的平臺都提供了的，對 printf 進行這種假設是合理的，因為它是 libc 的標準函數。
然而，有些 Port 雖然有默認實現，卻不能支持所有的平臺，例如線程操作的 Port，在常見的平臺中，如 linux、RT-Thread、FreeRTOS ，我們知道如何寫默認實現，但是這些實現又不通用，這時我們可以在默認實現中結合條件編譯，為常見的平臺提供默認實現，例如：
attribute((weak)) void port_thread_start(port_thread_t* thread) {pthread_mutex_lock(&(thread->mutex));pthread_cond_signal(&(thread->cond));pthread_mutex_unlock(&(thread->mutex));vTaskResume(thread->thread);}
這個例子中為 linux 和 FreeRTOS 提供了默認的線程啟動 Port 的實現，使用 linux 或者 FreeRTOS 的用戶可以通過條件編譯來直接使用默認實現。
而既不用 linux 也不用 FreeRTOS 的用戶，則會在編譯時遇到 #error，這提示他們要自己實現 port_thread_start()。
這種寫法還有一種好處，就是在不支持 weak 的平臺，例如 MSVC，就可以通過 _WIN32 條件編譯來進行跨平臺支持。
3. 邊緣但無默認實現的 Port
還有一類 Port，它們比較冷門，只有部分用戶會使用到，但是又難以提供默認的實現。例如用 port_reboot() 來重啟硬件，每個硬件平臺重啟硬件的 API 都是不同的，我們無法提供一個默認的實現。
但是，沒有這個 Port，也不影響系統的核心功能，只是在某些時候（例如開啟了超時自動重啟功能），又有這個 Port才行，這樣的 Port 就屬于是邊緣但無默認實現的 Port。
這時，就可以選擇將 Port 缺失的錯誤延后到運行時，具體在操作時，就可以編寫一個 weak 的實現，而這個實現中拋出一個運行時錯誤，例如：
attribute((weak)) void port_reboot(void){printf("Error: port_reboot() 需要用戶實現\r\n");while(1);}
這樣，只要不用到這個 Port，都可以編譯通過且順利運行，只有實際用到時，才會在運行時報錯。
weak 在 GCC 鏈接靜態(tài)庫時的問題
這里我想特別提示一種常見的 weak 失效的問題，這種問題目前我只發(fā)現在 gcc 鏈接靜態(tài)庫時包含 weak 會出現。
gcc 在鏈接靜態(tài)庫時，默認的行為是只要找到第一個（不管是不是弱符號），就會將其鏈接，然后停止繼續(xù)尋找，這樣一來，如果你的 weak 是被第一個找到的，那么強定義的函數就失效了。
這個問題有多種解決方案，我這里只提示一種，有更好的方案可以進qq交流群：577623681 大家一起討論。
解決方案：使用 "-Wl,--whole-archive" 選項來解決。當使用這個選項時，鏈接器將整個庫文件都包含在鏈接輸出文件中，而不考慮這些庫文件是否實際上被使用了。這樣就可以保證弱符號在整個庫中得到了正確的鏈接，并且在可執(zhí)行文件或其他庫中保持有效。
需要注意的是，當使用 "-Wl,--whole-archive" 選項時，可能會將一些不必要的庫文件鏈接到最終的可執(zhí)行文件或庫中，這可能會增加最終文件的大小。因此，應該僅在必要時使用這個選項。
定期以通俗易懂的方式分享嵌入式知識，關注公眾號，加星標，每天進步一點點。
聲明：
本號原創(chuàng)、轉載的文章、圖片等版權歸原作者所有，如有侵權，請聯系刪除。
關注、點贊、在看、轉發(fā)，支持優(yōu)質內容！
?
