看到DAY17這個序列號時我第一反應是這正好是很多人學ARM最容易卡住的位置。前面的匯編指令、開發(fā)板點燈都還算有趣到了“架構(gòu)”和“交叉編譯”這兩個詞兒抽象程度一下子拉高不少人是背完概念就跑了真到項目里一編譯就原形畢露。這篇就把ARM架構(gòu)和交叉編譯串起來講不念PPT直接從“為什么要這么設(shè)計”“為什么必須這么編譯”講起再給一套真實項目里能直接抄的搭建流程和踩坑記錄。適合剛?cè)腴T嵌入式或Linux底層開發(fā)的讀者也適合那些在目標板上編譯編譯到崩潰、想搞清楚交叉編譯背后邏輯的老哥。1. ARM架構(gòu)到底在講什么——從一句“精簡指令集”說起1.1 精簡指令集不是“指令少”而是“每條指令干一件事”ARM的標簽是RISC全稱精簡指令集計算。我見過很多人把RISC理解成“指令數(shù)量少”這個說法不能算錯但沒說到點子上。x86那種CISC復雜指令集一條指令能做的事特別多比如一條rep movsb就能拷一大塊內(nèi)存一條enter能直接把棧幀建好。這設(shè)計思路是“把活一次干完”對編譯器友好但對硬件極其不友好——CPU要為這些復雜指令設(shè)計大塊譯碼邏輯晶體管面積和功耗嘩嘩往上走。ARM反過來走的是“把大活拆成小活”的路子。一條指令就干一件簡單的事要么讀寫內(nèi)存要么做算術(shù)要么跳轉(zhuǎn)很少搞那種肌肉感很強的復合指令。程序員寫起來覺得啰嗦比如拷貝內(nèi)存要先用ldr加載再用str存儲兩條指令才能完成。但換來的是譯碼器非常簡單流水線短時序容易收斂芯片面積小功耗低。這就是ARM能橫掃移動端的底層原因——你不需要一條能搬倉庫的猛男指令你需要的是很多個干小活的工人日夜不停地流水線作業(yè)。用個更直白的類比x86像是一個定制家具作坊師傅自己畫圖、下料、組裝做一套復雜的柜子很在行但每個客戶都得單獨伺候機器很貴、工廠很大ARM像宜家流水線每個工人只負責擰一顆螺絲或貼一張標簽效率高、耗電少、廠房也小但你得按它的標準件思路來設(shè)計你的柜子。業(yè)界常說的“ARM架構(gòu)”其實有兩層含義這個必須分清楚。第一層是指令集架構(gòu)ISA也就是ARMv8、ARMv9這種帶v的版本號它規(guī)定的是“程序員能看到什么”比如有哪些寄存器AArch64有31個64位通用寄存器、指令怎么編碼、異常模型長什么樣。第二層是微架構(gòu)也就是Cortex系列的具體型號A72、A53、A76這些它們是指令集架構(gòu)的具體硬件實現(xiàn)。打個比方ISA是菜譜微架構(gòu)是按菜譜做菜的廚師班底不同廚師做出來的菜火候不一樣但菜譜上的主料配料都一樣。很多新手去搜“ARM架構(gòu)”看到Cortex-A72和ARMv8混在一起提容易懵其實前者是后者的一個實現(xiàn)而已。1.2 ARM產(chǎn)品線的三分法先搞清楚你在接觸哪條線ARM家的產(chǎn)品現(xiàn)在基本分三大類Cortex-A、Cortex-R、Cortex-M分別對應三個字母縮寫。Cortex-AApplication是應用處理器跑Linux、安卓追求絕對性能和完整的操作系統(tǒng)支持。你聽到的RK3576、RK3588、樹莓派、手機SoC基本都是這類。特點是帶MMU內(nèi)存管理單元支持虛擬內(nèi)存有豐富的外設(shè)接口和GPU、NPU這些伙伴IP。Cortex-MMicrocontroller是單片機核心目標是一個芯片幾毛錢、跑到幾塊錢的成本運行RTOS或者裸機程序比如STM32用M3/M4/M7小家電、傳感器、電機控制基本在這。特點是極端省電、中斷響應快、沒有MMU跑不了Linux這種重量級系統(tǒng)。Cortex-RReal-time是實時核心追求確定性和可預測的中斷延遲常見于汽車剎車系統(tǒng)、硬盤控制器、5G基站的實時處理路徑一般開發(fā)者接觸不多但它是ARM在汽車和通信領(lǐng)域特別賺錢的一條線。做技術(shù)選型和招聘準備的時候這條線非常關(guān)鍵。如果你準備做應用處理器方向的軟件開發(fā)那重心就是ARMv8/ARMv9架構(gòu)、異常等級、MMU、Caches外加交叉編譯和Linux系統(tǒng)移植時序如果你做MCU開發(fā)重心則是外設(shè)寄存器、中斷、低功耗設(shè)計指令集層面用到的也只是ARMv7-M的子集。別一上來就眉毛胡子一把抓先把身邊的板子屬于哪條線定下來學起來方向感完全不一樣。1.3 和x86的本質(zhì)差異功耗、生態(tài)與“攢機”模式雖然前面從CISC/RISC的角度講了兩者差異但這只是表層。真正讓ARM和x86走上完全不同道路的是商業(yè)和生態(tài)邏輯。x86被Intel和AMD兩家牢牢攥在手里生態(tài)封閉兼容性靠的是龐大的微碼和硬件兼容邏輯。x86 CPU為了做到“一份老軟件永遠能跑”內(nèi)部其實藏了一個小型的指令譯碼器轉(zhuǎn)微操作這層復雜度是硬扛下來的。所以你看到高性能x86核心動輒幾瓦到上百瓦功耗芯片面積巨大大部分晶體管用在了亂序執(zhí)行窗口、大緩存和譯碼邏輯上。ARM走的是IP授權(quán)的開放路線。ARM本身不賣芯片它賣的是芯片的“設(shè)計圖紙”授權(quán)SoC廠商拿這個圖紙加上自研的GPU、AI加速器、基帶、外設(shè)控制邏輯組合成一顆完整的SoC。所以你會看到手機廠商隔三差五喊“自研芯片”但大多數(shù)還是基于ARM公版核心魔改。這種攢機模式帶來的好處是靈活想要高性價比就上A53大核配節(jié)能設(shè)計想要性能就上X系列超大核同一芯片上可以混搭大小核。同樣的架構(gòu)思想應用范圍從傳感器里的M0一路覆蓋到服務器里的A76甚至Neoverse系列。功耗和生態(tài)的差異本質(zhì)上是被這兩套商業(yè)邏輯塑造出來的。x86的賣點是“絕對性能兼容性”ARM的賣點是“能效比定制化”。蘋果M系列芯片已經(jīng)證明只要認真設(shè)計ARM在桌面性能上也完全不虛x86但那是靠蘋果強大的芯片團隊實現(xiàn)的定制化微架構(gòu)拿公版A78去桌面那是另一個故事。2. 交叉編譯嵌入式世界里躲不開的“翻譯組”2.1 為什么不在目標板上直接編譯交叉編譯簡單說就是在一種架構(gòu)的機器上編譯出另一種架構(gòu)能運行的程序。你手里是一臺x86的電腦目標板子是ARM架構(gòu)的開發(fā)板你不能像native編譯那樣直接敲個gcc hello.c -o hello就完事得用專門的交叉編譯器生成ARM指令集的二進制。為什么不直接在開發(fā)板上編譯呢第一個痛點是性能。開發(fā)板的CPU干點小活還行但編譯是計算機領(lǐng)域數(shù)一數(shù)二的混合負載要大量內(nèi)存、要高速磁盤、要多核并行絕大多數(shù)ARM板子在內(nèi)存和I/O上是扛不住的。我見過有人在老式樹莓派上編譯OpenCV一編譯就是一夜甚至一天中途還沒法干別的體驗極差。第二個痛點是開發(fā)效率。編輯器、代碼瀏覽、版本管理、在線調(diào)試這一整套工具鏈如果都丟到板子上存儲先爆一半。開發(fā)環(huán)境這個事兒追求的是又大又全又順手而目標板追求的是專屬、精簡、把資源讓給業(yè)務邏輯這倆天生矛盾。第三個痛點是依賴鏈。編譯一個程序不只是編譯器的事還牽扯到頭文件、系統(tǒng)庫、構(gòu)建工具整個工具鏈在板子上能不能湊齊、版本對不對都是問題。與其在板子上折騰環(huán)境不如在高性能PC上搭一套交叉編譯環(huán)境統(tǒng)一管理依賴。就像想把一部中文小說翻譯成英文在倫敦發(fā)行你不需要把印刷機搬去倫敦從頭組稿而是在國內(nèi)請一隊翻譯、排版、校對交付成品再送過去印刷?！敖徊婢幾g”這個名字里的“交叉”二字點破了宿主機開發(fā)機和目標機運行設(shè)備的系統(tǒng)指令集不同這個核心矛盾。宿主機架構(gòu)是x86_64目標機是aarch64中間的“代溝”由交叉編譯器來彌合。2.2 讀懂交叉工具鏈名字里的每個字段交叉編譯器和普通編譯器的區(qū)別最直觀的就體現(xiàn)在工具鏈的命名上。一段常見的工具鏈名字長這樣aarch64-linux-gnu-gcc arm-linux-gnueabihf-gcc arm-none-eabi-gcc這三個前綴乍看像天書拆開了就是一套標準的三段式架構(gòu)-廠家-操作系統(tǒng)和ABI。第一部分是目標架構(gòu)。aarch64就是64位ARM的官方名字對應ARMv8開始的AArch64狀態(tài)arm則是32位ARM的統(tǒng)稱下面通常還隱含了具體是ARMv7、ARMv6需要看具體工具鏈文檔。第二部分一般是廠商或操作系統(tǒng)的標識最常見的是linux表示目標系統(tǒng)是Linux。第三部分是ABI和庫的組合gnu表示用glibc這套GNU C庫eabi表示嵌入式ABIhf表示硬浮點hard-floatgnueabihf就是基于glibc的硬浮點ABI工具鏈。而none這個詞很關(guān)鍵表示目標系統(tǒng)沒有操作系統(tǒng)也就是裸機環(huán)境比如單片機上的RT-Thread或裸機程序。有幾個容易踩混的坑必須說清楚。第一個是軟浮點和硬浮點的區(qū)別。早期的ARM核沒有浮點單元FPU浮點運算全靠編譯器用整數(shù)指令模擬這叫軟浮點ABI里叫soft傳參用通用寄存器后來有了FPU就用專門的vfp寄存器傳浮點參數(shù)這就是硬浮點hard-float。arm-linux-gnueabi和arm-linux-gnueabihf編譯出來的程序浮點參數(shù)傳遞規(guī)則完全不一樣二者混用會導致鏈接報錯或者運行時參數(shù)錯亂。第二個是EABI和普通ABI的差異。EABI是嵌入式Linux協(xié)會給ARM定的一套標準對結(jié)構(gòu)體對齊、函數(shù)調(diào)用約定、浮點處理方式都做了嚴格規(guī)定Linux生態(tài)里基本都走這套你用arm-linux-gnueabihf和arm-linux-gnueabi選錯的話鏈接階段經(jīng)常會出現(xiàn)奇怪的對齊錯誤。第三個是32位和64位不能混用。很多人以為ARM工具鏈是通用的先裝一個gcc-arm-linux-gnueabihf覺得差不多編譯完拷到64位開發(fā)板一跑直接Exec format error。其實32位ARM和64位ARM的指令集完全不同前者是ARMv7時代的設(shè)計后者是ARMv8的AArch64狀態(tài)一個是32位指令寬度、31個32位寄存器一個是固定32位指令寬度但有31個64位通用寄存器二進制格式也不一樣。所以選工具鏈之前第一件事就是用uname -m看一下板子的架構(gòu)armv7l是32位aarch64是64位這是最鐵的判據(jù)。2.3 交叉編譯的隱含依賴頭文件、庫、sysroot很多人以為交叉編譯器就是“換一個不同名字的gcc”編譯指令從gcc換成aarch64-linux-gnu-gcc就完事了。真實項目里這是第一步但遠不是全部。交叉編譯的復雜性很大一部分來自“你到底在跟誰的頭文件和庫去編譯鏈接”。普通本機編譯編譯器默認從系統(tǒng)里的/usr/include找頭文件從/usr/lib找?guī)煲驗樗拗鳈C系統(tǒng)本身就是目標系統(tǒng)。但交叉編譯時目標系統(tǒng)是開發(fā)板上的那個Linux它有自己的庫、自己的頭文件、自己的ABI。你的開發(fā)機上的glibc是x86版本的拿到ARM板子上根本不能用。于是就有了sysroot系統(tǒng)根目錄的概念一個刻意做出來的、模擬目標板根文件系統(tǒng)根目錄的目錄。工具鏈編譯時會從這個目錄里找include和lib而不是從宿主機系統(tǒng)里找。有的交叉編譯器會帶一個內(nèi)建的sysroot比如Linaro和ARM官方的工具鏈解壓后自帶一套目標板的頭文件和基礎(chǔ)庫有的不帶需要你手動指定--sysroot/path/to/rootfs指向你自己跟目標板系統(tǒng)版本一致的文件系統(tǒng)。這里就是很多老鳥都栽過的坑交叉編譯的時候沒接目標板的sysroot程序用的是工具鏈自帶的舊版glibc和庫編出來的二進制在開發(fā)板上跑不起來最典型的就是GLIBC_2.27 not found或者libxxx.so.1 not found這種錯誤。原因就是工具鏈的glibc版本比板子的系統(tǒng)庫版本新或者板子上根本沒有對應的那個共享庫。正確處理方式一是盡量用和板子系統(tǒng)版本匹配的工具鏈二是如果板子系統(tǒng)有定制直接拿板子的/lib和/usr/include打包成sysroot編譯時通過--sysroot指進去。這個習慣如果能養(yǎng)好后面折騰Qt交叉編譯、移植各種庫會省一大半心。3. 從0搭一套可用的ARM交叉編譯環(huán)境實操向3.1 工具鏈選型與下載Linaro還是ARM官方用發(fā)行版還是自己裝現(xiàn)在交叉工具鏈的選擇比以前多了不少。最常見的兩個大方向一個是Linaro維護的GCC工具鏈一個是ARM官方的arm-gnu-toolchain這兩個技術(shù)內(nèi)核都是GCC區(qū)別主要在于針對嵌入式板子的優(yōu)化、sysroot預置內(nèi)容和發(fā)布節(jié)奏。Linaro的工具鏈在嵌入式Linux開發(fā)圈用得特別廣版本全歷史和板子廠商的兼容文檔多很多開發(fā)板廠家直接拿它當基準環(huán)境ARM官方的則是對自家IP的適配最“正統(tǒng)”。還有一條路是直接用發(fā)行版自帶的包Debian/Ubuntu里可以用apt install gcc-aarch64-linux-gnu直接裝RedHat系是gcc-aarch64-linux-gnu這個包。方便是真方便但有個隱患倉庫里的版本往往比較老如果你要編譯的是很新的軟件、或者目標板系統(tǒng)的庫比較新工具鏈可能跟不上。我自己的習慣是下載Linaro的新版工具鏈放到/opt下固定版本號這樣每個項目都能復現(xiàn)出問題也知道是哪一版工具鏈的事而不是被apt悄悄升級坑一把。下載的時候注意三個事情。第一是選對架構(gòu)下載的是aarch64還是arm32位的工具鏈第二是選對格式x86_64的發(fā)行版選x86_64包不要下成arm版本的第三是確認glibc版本和你要跑的目標板系統(tǒng)別差太遠工具鏈太新會編譯出在板子上跑不了的動態(tài)庫依賴。如果目標板子是很老的系統(tǒng)寧可找對應的老版本工具鏈也不要腦門一熱上最新版。3.2 環(huán)境變量與第一個交叉編譯實例把工具鏈解壓到/opt/arm-gnu-toolchain-13.2-rel1-aarch64-linux-gnu/之后第一件事是把bin目錄加入PATH。我建議給每個項目寫一個環(huán)境腳本不要直接寫進~/.bashrc因為不同項目可能用不同版本的工具鏈全局寫死反而容易互相污染。腳本內(nèi)容大致這樣#!/bin/bash export PATH/opt/arm-gnu-toolchain-13.2-rel1-aarch64-linux-gnu/bin:$PATH export CROSS_COMPILEaarch64-none-linux-gnu- export ARCHarm64第一行把工具鏈bin目錄塞進PATH第二行定義交叉編譯相關(guān)工具的前綴第三行ARCHarm64是給內(nèi)核等項目的構(gòu)建系統(tǒng)看的。做完之后寫個最簡單的hello.c試試水#include stdio.h int main(void) { printf(hello arm, from day17\n); return 0; }編譯命令很直觀aarch64-none-linux-gnu-gcc hello.c -o hello_arm64然后馬上用file命令檢查產(chǎn)物file hello_arm64輸出大概是hello_arm64: ELF 64-bit LSB executable, ARM aarch64, version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux-aarch64.so.1, BuildID[sha1]..., not stripped看到“ARM aarch64”就說明這個二進制確實是ARM架構(gòu)的了。如果順手用ldd看一下會得到一個警告或“not a dynamic executable”一類的提示——因為ldd默認是宿主機x86的解析器去識別動態(tài)庫依賴你拿它去看ARM的二進制是隔空診斷得用aarch64-none-linux-gnu-readelf -d這類工具看ARM格式的動態(tài)鏈接信息。這個細節(jié)很多人一開始會慌以為程序有問題其實只是檢測工具用錯了。如果你是在x86的電腦上直接執(zhí)行這個hello_arm64會報cannot execute binary file: Exec format error這是正常的因為x86內(nèi)核不認識ARM指令。想在本機驗證運行的話可以用qemu-aarch64配合-L指定sysroot來模擬這在測試階段特別有用后面單獨講。3.3 用CMake管理交叉編譯toolchain文件寫法參考實際項目很少用一條gcc命令硬編基本都是CMake或Makefile。CMake做交叉編譯的思路是“用一個特殊的工具鏈文件告訴構(gòu)建系統(tǒng)目標平臺信息”。我一般這樣寫aarch64-toolchain.cmakeset(CMAKE_SYSTEM_NAME Linux) set(CMAKE_SYSTEM_PROCESSOR aarch64) set(CMAKE_C_COMPILER aarch64-none-linux-gnu-gcc) set(CMAKE_CXX_COMPILER aarch64-none-linux-gnu-g) set(CMAKE_FIND_ROOT_PATH /opt/arm-sysroot) set(CMAKE_FIND_ROOT_PATH_MODE_PROGRAM NEVER) set(CMAKE_FIND_ROOT_PATH_MODE_LIBRARY ONLY) set(CMAKE_FIND_ROOT_PATH_MODE_INCLUDE ONLY)第一塊兩個CMAKE_SYSTEM_*變量是給CMake一個“我在為誰編譯”的提示CMAKE_C_COMPILER和CMAKE_CXX_COMPILER指定交叉編譯器和交叉C編譯器。CMAKE_FIND_ROOT_PATH指向sysroot也就是目標板的根文件系統(tǒng)路徑下面三行MODE的含義是找程序時不去rootfs里找NEVER但找?guī)旌皖^文件時只去rootfs里找ONLY這是交叉編譯最合理的行為避免把開發(fā)機本地的庫混進去。然后在項目根目錄執(zhí)行mkdir build cd build cmake .. -DCMAKE_TOOLCHAIN_FILE../aarch64-toolchain.cmake make這樣整個項目的依賴查找、編譯、鏈接就全部限定在ARM體系內(nèi)了。這里有個經(jīng)驗CMAKE_FIND_ROOT_PATH用的是sysroot的話記得確保你的/opt/arm-sysroot里面有目標板系統(tǒng)對應的usr/include和usr/lib否則項目里find_package出來的依賴會和真實板子對不上號。自己打包sysroot的話直接用rsync從板子上同步/lib/usr/lib/usr/include下來就好注意別把proc、sys、dev這些虛擬文件系統(tǒng)目錄拖下來。3.4 進階指引交叉編譯Qt這類重量級項目的大體思路熱詞里好幾個人搜的是“qt5.12.10交叉編譯”“RK3576 qt交叉編譯環(huán)境”看來有不少朋友卡在Qt這關(guān)。Qt交叉編譯比普通C項目復雜本質(zhì)上是因為Qt本身由一堆模塊組成core、gui、widgets、network、sql等等每個模塊都要針對目標架構(gòu)編譯一套還要考慮到目標板上的顯示后端比如linuxfb、eglfs、wayland和GPU驅(qū)動。大體流程是先用交叉工具鏈編譯目標板的sysroot依賴庫如libjpeg、libpng、freetype然后下載Qt源碼進入configure階段用-xplatform指定目標平臺描述文件。平臺描述文件一般在qtbase/mkspecs/linux-aarch64-gnu-g這樣的目錄下你要打開qmake.conf把CROSS_COMPILE指到你的交叉工具鏈前綴。然后configure的時候帶上一堆選項-prefix /usr/local/qt5安裝到目標板的路徑、-opensource -confirm-license、-no-opengl如果板子沒有GPU驅(qū)動就先關(guān)掉等等。編譯完之后把指定prefix目錄整個拷到目標板。這里面的關(guān)鍵是和你用的具體板子高度耦合RK3576有Mali GPU配置OpenGL后端時要跟廠商的GPU驅(qū)動庫配合。沒有一塊具體的板子在前面擺著直接談通用步驟意義不大但核心邏輯和普通C項目完全一致——交叉工具鏈、sysroot、目標平臺配置三件套。在板子到手之前用一個通用的aarch64 qmake配置把hello widget編起來先建立“Qt也能交叉編譯”的信心更重要。4. 我踩過的坑ARM交叉編譯問題速查與排查技巧4.1 “cannot execute binary file”與“Exec format error”這個錯誤幾乎每個交叉編譯新手都會遇到意思是“文件格式無法執(zhí)行”。最常見的原因是你在x86的開發(fā)機上直接運行了ARM架構(gòu)的程序。但其實還有幾個不常見的變種值得說說。第一個變種是文件確實編譯成x86了。比如某次編譯時CC變量沒生效Makefile里的CCgcc覆蓋了交叉編譯器產(chǎn)物是個x86的ELF你拷到板子上跑就報這個錯。排查辦法很簡單file 產(chǎn)物看是x86-64還是ARM aarch64一秒定位。第二個變種是改了交叉編譯器但鏈接器沒改。有的項目會同時用gcc和ld如果LD還是指向系統(tǒng)x86的ld鏈接階段就會報與架構(gòu)不匹配相關(guān)的錯誤或者生成出不倫不類的產(chǎn)物。所以交叉編譯時最好把所有LD、AR、AS都指到交叉工具鏈對應的程序上最省心的辦法就是用CROSS_COMPILE前綴統(tǒng)一設(shè)置。第三個變種是動態(tài)鏈接器的路徑問題。有時候ARM程序拷到板子上一運行就報No such file or directory看起來很迷惑——文件明明存在啊。其實這是內(nèi)核找不到動態(tài)加載器interpreter比如程序里寫明/lib/ld-linux-aarch64.so.1但板子這個路徑?jīng)]有這個文件。用readelf -l看程序頭里的INTERP段就能確認。解決辦法要么同步對應版本的glibc到板子上要么靜態(tài)編譯完事。4.2 “cannot find -lxxx”庫路徑與依賴鏈的坑鏈接時報/usr/bin/ld: cannot find -lxxx常規(guī)理解是“缺庫”。交叉編譯場景下還要再加一層追問缺的是哪個架構(gòu)的庫交叉編譯時鏈接器找的是sysroot里的libxxx.so如果你只在本機x86環(huán)境裝過libxxx-dev交叉編譯是找不到的。你需要下載對應架構(gòu)的庫比如用apt裝libxxx-dev:arm64或者手動把ARM版的.so放進sysroot。但這里有個更隱蔽的坑鏈接器找到了libxxx.so但它可能只是一個符號鏈接指向真實的libxxx.so.1.2.3。如果你從外部拷貝庫的時候只拷了那個軟鏈接文件沒有跟著拷貝真正的庫文件鏈接器就會報cannot find -lxxx或者提示文件格式不對。用ls -l看下那個目錄里的libxxx.so到底是不是軟鏈接是的話一定把鏈接目標和鏈接本身一起拷過去。還有一類情況鏈接器找不到庫其實是因為沒有把-L指向正確的搜索路徑。CMake里面如果CMAKE_FIND_ROOT_PATH_MODE_LIBRARY設(shè)置不當它可能只在宿主機的/usr/lib/x86_64-linux-gnu找?guī)爝@時候即使sysroot里有ARM庫也搜不到。檢查一下CMake的CMAKE_LIBRARY_PATH和CMAKE_FIND_ROOT_PATH是否把路徑盯對了別一條路走到黑。4.3 浮點ABI、體系架構(gòu)與“selected processor does not support”有的ARM舊項目會遇到這種鏈接錯誤或編譯錯誤error: selected processor does not support smull r0, r1, r0, r1意思是編譯選項里的浮點指令或特定指令在當前選的處理器架構(gòu)里不受支持。原因一般是編譯選項里指定了錯誤的-mcpu、-march或-mfloat-abi參數(shù)。硬浮點和軟浮點混用是這個錯誤的頭號來源。如果你的工具鏈是arm-linux-gnueabihf但項目里指定了-mfloat-abisoft那么編譯器生成的代碼調(diào)用的ABI規(guī)則和工具鏈默認的硬浮點不一致編譯和鏈接都會出問題。反過來如果你的板子CPU確實沒有FPU硬要用硬浮點工具鏈去編運行時會出非法指令錯誤。判斷板子是否支持硬浮點可以用cat /proc/cpuinfo看Features有沒有vfp、neon字段ARMv8之前很需要糾結(jié)這個ARMv8之后的AArch64默認都有FPU和NEON反而省心多了。還有一個常見問題是32位ARM和64位ARM混用。有人拿arm-linux-gnueabihf工具鏈去編譯給64位板子用的程序file一看是針對32位的自然跑不起來。正確思路是明確板子是armv7l還是aarch64然后只看對應的工具鏈和編譯選項別指望一個工具鏈通吃。4.4 動態(tài)庫運行時找不到GLIBC、LD_LIBRARY_PATH與qemu模擬交叉編譯的程序在開發(fā)板上跑起來外帶一個“加載器”概念。程序頭部會寫明動態(tài)加載器路徑一般指向/lib/ld-linux-aarch64.so.1。動態(tài)加載器負責找到程序依賴的所有共享庫然后跳轉(zhuǎn)到main執(zhí)行。如果加載器和庫版本對不上最常見的錯誤是./hello: /lib/aarch64-linux-gnu/libm.so.6: version GLIBC_2.27 not found (required by ./hello)這說明工具鏈的glibc版本比板子的glibc新程序運行要求板子上有更高的GLIBC版本。解決方向有兩個一是換用版本更老的工具鏈讓編譯出來的動態(tài)庫依賴低于或等于板子系統(tǒng)版本二是把板子的系統(tǒng)庫整個更新——但嵌入式板子往往不能隨便升級系統(tǒng)所以更推薦前者。做量產(chǎn)項目的時候我會把工具鏈的glibc版本和板子的glibc版本記錄在項目說明里作為選型基準之一。另一個運行時的經(jīng)典問題動態(tài)庫里帶了非標準路徑的依賴。比如你交叉編譯一個庫時把它裝到了/usr/local/opt編出來的程序在板子上找?guī)鞎r會去開發(fā)板根文件系統(tǒng)的/usr/local/opt找但板子上沒這個路徑于是“not found”。如果不想改鏈接路徑可以臨時用LD_LIBRARY_PATH/xxx/yyy來指定但這只是臨時手段正式方案是用-rpath把搜索路徑編進二進制里或者把庫放進系統(tǒng)默認的/usr/lib。最后說下qemu在調(diào)試交叉編譯產(chǎn)物時的價值。在開發(fā)機上裝好qemu-user后可以用qemu-aarch64 -L /opt/arm-sysroot ./hello_arm64-L指定的是ARM系統(tǒng)根目錄這樣qemu就能從sysroot里找動態(tài)庫。這個方式在跑單元測試、驗證命令行工具時特別有用不用每次都把程序拷到板子上。我常用的組合是交叉編譯產(chǎn)物qemu-aarch64CI流水線能在沒有開發(fā)板的情況下完成大部分功能測試只有涉及真實硬件外設(shè)時才需要上板驗證。5. 給新手的一套“不過腦子”實踐建議5.1 固定工具鏈版本并記錄環(huán)境信息交叉編譯最讓人頭疼的事之一就是環(huán)境不可復現(xiàn)。同一個項目上個月用工具鏈A編譯能跑這個月升級到工具鏈B就各種詭異錯誤。建議每個項目在根目錄放一個toolchain_version.txt把工具鏈版本、sysroot來源、目標板架構(gòu)、板子系統(tǒng)鏡像版本都寫清楚。這個習慣在多人協(xié)作時更值錢別人接手項目不用靠猜。工具鏈版本我會這樣記錄工具鏈: arm-gnu-toolchain-13.2.rel1-x86_64-aarch64-none-linux-gnu 目標板: RK3576 evb1, ubuntu22.04 rootfs sysroot: board_rootfs_20240615.tar.gz 編譯器: aarch64-none-linux-gnu-gcc (Build 13.2)當同事說“我這邊編出來上板就崩”的時候第一件事不是看代碼而是對比這個文件。5.2 先靜態(tài)編譯跑通再改動態(tài)鏈接剛開始動手交叉編譯時不要一上來就搞動態(tài)鏈接和一堆-L、-rpath參數(shù)。先用靜態(tài)編譯把整個流程跑通把工具鏈、CMake配置、sysroot路徑這些環(huán)境問題全部排掉再慢慢換成動態(tài)鏈接。靜態(tài)編譯的命令很簡單aarch64-none-linux-gnu-gcc -static hello.c -o hello_static這樣產(chǎn)出的二進制不依賴目標板的動態(tài)庫拷上去直接跑大概率能跑通。如果連靜態(tài)編譯都在板子上起不來那就是二進制格式或加載器的問題和動態(tài)庫依賴完全無關(guān)排查方向會干凈很多。等靜態(tài)版驗證完環(huán)境再把動態(tài)庫一個一個加進來出了問題也知道是哪個庫引起的。5.3 用三板斧定位交叉編譯問題遇到交叉編譯相關(guān)的報錯我的排查順序向來是固定的第一看file 產(chǎn)物確認架構(gòu)第二看readelf -d 產(chǎn)物查動態(tài)庫依賴和NEEDED第三看readelf -l 產(chǎn)物找解釋器路徑。這三個命令基本能覆蓋九成問題file hello_arm64 aarch64-none-linux-gnu-readelf -d hello_arm64 | head -30 aarch64-none-linux-gnu-readelf -l hello_arm64 | grep -A1 INTERPfile確認架構(gòu)對不對readelf -d列出程序依賴哪些共享庫如果某個庫沒有版本號或路徑異常就是那里出問題readelf -l里的INTERP段可以看到動態(tài)加載器路徑如果路徑不對直接決定程序能否啟動。6. 寫在最后ARM架構(gòu)與交叉編譯這道坎跨過去之后回看會覺得很值得。ARM的RISC設(shè)計思想在很多現(xiàn)代處理器里都有影子理解它之后看蘋果芯片、看高通驍龍、看各種SoC的評測都不會再是一團毛線球。交叉編譯也是同理它不只是一個工具鏈名字更是一套“宿主-目標”分離的開發(fā)模型搞懂了它以后移植任何東西——Linux內(nèi)核、Qt、數(shù)據(jù)庫、AI推理框架——底層邏輯都是一樣的。原生gcc編譯就像是請一個本地大廚材料就地取材口味天然匹配。交叉編譯器則像是從外地請來一位客座大廚能做一桌正宗的外地菜但你必須把生抽、老抽、蠔油這些當?shù)卣{(diào)料sysroot里的庫和頭文件都提前備齊否則它就只能干瞪眼。備好調(diào)料、讀透菜譜架構(gòu)文檔、加上這一天積累的排錯經(jīng)驗接下來寫到DAY18的時候你已經(jīng)可以像一個老手那樣在工程板、開發(fā)板、虛擬機之間來回穿梭從容地給每個平臺交付正確的二進制了。