1. 從一次失敗的BPF程序移植說起最近在將一個(gè)原本在x86_64平臺(tái)上運(yùn)行良好的BPFBerkeley Packet Filter示例程序移植到一臺(tái)基于ARM64架構(gòu)的嵌入式設(shè)備上時(shí)我遇到了一個(gè)令人困惑的問題。程序編譯順利加載也成功了但預(yù)期的網(wǎng)絡(luò)事件追蹤日志卻遲遲沒有輸出。沒有崩潰沒有錯(cuò)誤信息只有一片沉默。這讓我意識(shí)到在ARM64這個(gè)日益普及的平臺(tái)上調(diào)試BPF程序與在熟悉的x86_64上有著截然不同的“風(fēng)景”。BPF技術(shù)特別是eBPF因其在內(nèi)核中安全、高效地執(zhí)行代碼的能力正被廣泛應(yīng)用于網(wǎng)絡(luò)、可觀測性和安全領(lǐng)域。而ARM64架構(gòu)憑借其出色的能效比在移動(dòng)設(shè)備、服務(wù)器乃至邊緣計(jì)算節(jié)點(diǎn)中占據(jù)了半壁江山。當(dāng)這兩者相遇開發(fā)者往往會(huì)發(fā)現(xiàn)那些在x86上看似順理成章的工具鏈和調(diào)試方法在ARM64上需要一些新的視角和技巧。這篇內(nèi)容就是基于這次真實(shí)的調(diào)試經(jīng)歷梳理出一套在64位ARMAArch64平臺(tái)上有效調(diào)試BPF程序的實(shí)戰(zhàn)指南。無論你是在為樹莓派開發(fā)網(wǎng)絡(luò)監(jiān)控工具還是在基于鯤鵬或飛騰的服務(wù)器上部署可觀測性探針希望這些踩過的坑和總結(jié)的方法能幫你更快地定位問題讓BPF程序在ARM64上順暢運(yùn)行。我們將繞過那些寬泛的概念直接切入具體的問題場景、工具使用和排查邏輯。2. ARM64與x86_64BPF調(diào)試的環(huán)境差異根源在開始敲調(diào)試命令之前我們必須先理解調(diào)試的對(duì)象和環(huán)境有何不同。把x86_64上的經(jīng)驗(yàn)生搬硬套到ARM64上是很多問題的起點(diǎn)。2.1 指令集與內(nèi)存模型帶來的根本差異最核心的差異源于指令集架構(gòu)ISA。x86_64是復(fù)雜指令集CISC而ARM64是精簡指令集RISC。這直接影響到BPF驗(yàn)證器對(duì)程序的校驗(yàn)以及最終生成的指令。字節(jié)序Endiannessx86_64是典型的小端序Little-Endian架構(gòu)。而ARM64在理論上是雙端序的但在Linux實(shí)踐和絕大多數(shù)應(yīng)用場景中也采用小端序。雖然對(duì)于常規(guī)應(yīng)用這通常不是問題但在BPF程序中當(dāng)你通過bpf_probe_read_kernel()等輔助函數(shù)讀取內(nèi)核結(jié)構(gòu)體或者直接處理網(wǎng)絡(luò)包數(shù)據(jù)特別是協(xié)議頭時(shí)必須對(duì)數(shù)據(jù)的字節(jié)序保持高度警惕。網(wǎng)絡(luò)字節(jié)序是大端序而主機(jī)字節(jié)序是小端序這個(gè)轉(zhuǎn)換在跨平臺(tái)時(shí)更容易因疏忽而出錯(cuò)。調(diào)用約定Calling Convention函數(shù)調(diào)用時(shí)參數(shù)如何傳遞、寄存器如何保存x86_64和ARM64的規(guī)則完全不同。BPF程序雖然不直接進(jìn)行復(fù)雜的函數(shù)調(diào)用但它會(huì)通過輔助函數(shù)Helper Functions與內(nèi)核交互。內(nèi)核中的輔助函數(shù)接口是架構(gòu)無關(guān)的但底層實(shí)現(xiàn)需要處理這些差異。作為BPF開發(fā)者我們更常遇到的是在訪問棧空間、上下文struct pt_regs中的參數(shù)時(shí)偏移量可能因架構(gòu)而異。例如在追蹤系統(tǒng)調(diào)用時(shí)獲取系統(tǒng)調(diào)用參數(shù)所對(duì)應(yīng)的寄存器索引在兩種架構(gòu)上是不同的。對(duì)齊AlignmentARM64對(duì)內(nèi)存訪問的對(duì)齊要求通常比x86_64更嚴(yán)格。未對(duì)齊的內(nèi)存訪問在x86上可能只是性能損失但在ARM64上可能導(dǎo)致數(shù)據(jù)錯(cuò)誤甚至陷入異常。BPF驗(yàn)證器會(huì)盡力阻止未對(duì)齊的訪問但有些通過內(nèi)聯(lián)匯編或特殊方式構(gòu)造的訪問可能在驗(yàn)證時(shí)被放過卻在特定架構(gòu)的JIT編譯后運(yùn)行出錯(cuò)。2.2 內(nèi)核配置與工具鏈的隱性門檻你的目標(biāo)ARM64設(shè)備的內(nèi)核配置可能與你開發(fā)的x86服務(wù)器有天壤之別。內(nèi)核配置選項(xiàng)BPF功能依賴一系列內(nèi)核配置選項(xiàng)如CONFIG_BPF,CONFIG_BPF_JIT,CONFIG_BPF_SYSCALL,CONFIG_BPF_EVENTS等。嵌入式設(shè)備或某些定制化內(nèi)核為了精簡體積可能會(huì)關(guān)閉部分非核心的BPF特性例如CONFIG_BPF_KPROBE_EVENTS或CONFIG_BPF_TRACING。這會(huì)導(dǎo)致你的kprobe/tracepoint程序無法掛載。你需要檢查/proc/config.gz如果存在或使用zcat /proc/config.gz | grep BPF來確認(rèn)。工具鏈的完整性在x86開發(fā)機(jī)上交叉編譯ARM64的BPF程序或者直接在ARM64設(shè)備上編譯都需要完整的工具鏈。關(guān)鍵組件包括LLVM/Clang ( 10.0)用于將C代碼編譯為BPF字節(jié)碼。確保其支持-target bpf選項(xiàng)。內(nèi)核頭文件必須與目標(biāo)設(shè)備運(yùn)行的內(nèi)核版本匹配。直接從設(shè)備拷貝/usr/include/linux、/usr/include/asm等目錄或者使用kernel-devel包是最佳實(shí)踐。版本不匹配是頭文件包含錯(cuò)誤和編譯失敗的常見原因。libbpf庫現(xiàn)代BPF程序推薦使用libbpf進(jìn)行加載和管理。你需要為ARM64交叉編譯或安裝此庫。注意不要假設(shè)你的嵌入式設(shè)備鏡像里預(yù)裝了編譯工具。很多精簡的根文件系統(tǒng)連gcc都沒有。準(zhǔn)備一個(gè)與目標(biāo)內(nèi)核版本匹配的交叉編譯環(huán)境是更可靠的做法。3. 搭建ARM64 BPF調(diào)試環(huán)境從編譯到加載一個(gè)可靠的調(diào)試環(huán)境是成功的一半。下面是在ARM64平臺(tái)上為BPF開發(fā)準(zhǔn)備環(huán)境的詳細(xì)步驟。3.1 交叉編譯工具鏈的配置如果你在x86_64主機(jī)上開發(fā)交叉編譯是首選。這里以Ubuntu/Debian為例# 1. 安裝交叉編譯工具鏈 sudo apt-get update sudo apt-get install gcc-aarch64-linux-gnu g-aarch64-linux-gnu # 2. 安裝LLVM/Clang確保版本足夠新 sudo apt-get install clang llvm # 3. 獲取目標(biāo)設(shè)備的內(nèi)核頭文件 # 方法A如果設(shè)備有網(wǎng)絡(luò)可以直接安裝 # ssh rootarm-device apt-get install linux-headers-$(uname -r) # scp -r rootarm-device:/usr/include/linux /path/to/your/sysroot/usr/include/ # scp -r rootarm-device:/usr/include/asm /path/to/your/sysroot/usr/include/ # scp -r rootarm-device:/usr/include/asm-generic /path/to/your/sysroot/usr/include/ # 方法B從內(nèi)核源碼構(gòu)建更推薦確保絕對(duì)匹配 # 假設(shè)你已下載并解壓了與設(shè)備內(nèi)核版本完全一致的源碼 cd /path/to/linux-kernel-source make ARCHarm64 CROSS_COMPILEaarch64-linux-gnu- defconfig make ARCHarm64 CROSS_COMPILEaarch64-linux-gnu- prepare # 生成頭文件 # 生成的頭部文件主要在源碼根目錄的 include/generated 和 arch/arm64/include/generated 下。 # 你需要將它們與 include/linux, arch/arm64/include/asm 等目錄一起整合到你的sysroot中。3.2 編譯BPF程序針對(duì)ARM64的編譯命令編譯BPF程序時(shí)必須明確指定目標(biāo)架構(gòu)。一個(gè)典型的編譯命令如下# 在x86主機(jī)上為ARM64內(nèi)核編譯BPF程序 clang -O2 -g -target bpf -D__TARGET_ARCH_arm64 \ -I/path/to/arm64/sysroot/usr/include \ -I/path/to/linux-kernel-source/include \ -c your_bpf_program.c -o your_bpf_program.o # 關(guān)鍵參數(shù)解釋 # -target bpf: 指定輸出為BPF字節(jié)碼。 # -D__TARGET_ARCH_arm64: 定義宏告訴內(nèi)核頭文件我們正在為ARM64編譯。這會(huì)影響一些架構(gòu)相關(guān)的宏定義如asm/syscall.h中的系統(tǒng)調(diào)用號(hào)。 # -I: 包含正確的頭文件路徑確保找到ARM64架構(gòu)特定的定義如asm/bpf_perf_event.h。編譯后你可以使用llvm-objdump工具來初步檢查生成的BPF字節(jié)碼llvm-objdump -S your_bpf_program.o這可以查看BPF匯編指令雖然可讀性不如源碼但能確認(rèn)程序是否被正確編譯。3.3 加載與初步驗(yàn)證BPF工具集的使用將編譯好的.o文件拷貝到ARM64目標(biāo)設(shè)備上使用bpftool進(jìn)行加載和檢查。bpftool是現(xiàn)代BPF生態(tài)中最核心的瑞士軍刀。# 1. 查看BPF程序信息驗(yàn)證是否包含有效程序 bpftool prog show # 2. 加載BPF程序假設(shè)是跟蹤點(diǎn)程序 # 首先獲取跟蹤點(diǎn)格式cat /sys/kernel/debug/tracing/events/syscalls/sys_enter_openat/format # 然后使用libbpf方式加載需要用戶態(tài)加載器或者用bpftool加載由libbpf編譯的骨架skeleton對(duì)象。 # 這里展示一個(gè)簡單的通過bpftool prog load加載到特定掛載點(diǎn)的方式適用于一些簡單程序類型 bpftool prog load your_bpf_program.o /sys/fs/bpf/your_prog type tracepoint \ attach_tracepoint:syscalls:sys_enter_openat # 3. 查看已加載程序的詳細(xì)信息至關(guān)重要 bpftool prog dump xlated id PROG_ID # 顯示驗(yàn)證器轉(zhuǎn)換后的指令人類可讀性更好 bpftool prog dump jited id PROG_ID # 顯示JIT編譯后的ARM64機(jī)器碼用于深度調(diào)試bpftool prog dump xlated的輸出是調(diào)試的第一站。它能清晰地展示出BPF驗(yàn)證器“眼中”的程序邏輯包括所有內(nèi)存訪問、輔助函數(shù)調(diào)用和分支。如果程序邏輯有誤這里往往能看出端倪。4. 當(dāng)BPF程序靜默失敗系統(tǒng)化的排查鏈路回到我最初遇到的問題程序加載成功但沒產(chǎn)生任何輸出。以下是系統(tǒng)化的排查步驟它適用于大多數(shù)“靜默失敗”的場景。4.1 第一步確認(rèn)程序真的被加載并附加了嗎不要相信感覺相信數(shù)據(jù)。# 檢查程序是否在內(nèi)核列表中 bpftool prog list | grep -A5 -B5 your_program_name # 檢查程序是否附加到了預(yù)期的事件上 bpftool prog show id PROG_ID --pretty在輸出中關(guān)注pids字段哪個(gè)用戶態(tài)進(jìn)程在持有它、attached字段附加類型以及map_ids關(guān)聯(lián)的映射。如果attached為空說明程序雖然加載了但并未綁定到任何事件觸發(fā)器上。4.2 第二步檢查BPF映射Map——數(shù)據(jù)的生命線BPF程序通過映射與用戶態(tài)通信輸出日志、統(tǒng)計(jì)數(shù)據(jù)。映射創(chuàng)建失敗或權(quán)限錯(cuò)誤是靜默的常見原因。# 1. 列出所有BPF映射 bpftool map list # 2. 查看特定映射的詳細(xì)信息、內(nèi)容 bpftool map dump id MAP_ID映射是否存在確保你的程序定義的映射在列表中。映射類型和鍵值大小是否正確在ARM64上由于對(duì)齊和填充結(jié)構(gòu)體大小可能與x86不同。使用sizeof()打印確認(rèn)。用戶態(tài)程序在讀取映射嗎如果BPF程序向環(huán)形緩沖區(qū)BPF_MAP_TYPE_RINGBUF或性能事件BPF_MAP_TYPE_PERF_EVENT_ARRAY寫入數(shù)據(jù)但用戶態(tài)消費(fèi)者沒有運(yùn)行或沒有正確調(diào)用poll()/epoll()數(shù)據(jù)就會(huì)被默默丟棄。確保你的用戶態(tài)加載器在持續(xù)運(yùn)行并讀取映射。4.3 第三步深入內(nèi)核日志與跟蹤事件BPF驗(yàn)證器和運(yùn)行時(shí)會(huì)在內(nèi)核日志中留下痕跡。這是最重要的信息源。# 使用dmesg查看內(nèi)核環(huán)緩沖區(qū)日志注意時(shí)間戳 sudo dmesg -T | tail -50 # 或者持續(xù)監(jiān)控 sudo dmesg -w # 更精準(zhǔn)地查看BPF相關(guān)的日志 sudo cat /sys/kernel/debug/tracing/trace_pipe在dmesg中搜索 “BPF”, “bpf”, “verifier” 等關(guān)鍵詞。常見的錯(cuò)誤信息包括invalid bpf_context access 程序試圖以錯(cuò)誤的方式訪問BPF上下文ctx。R# 未初始化 BPF寄存器在使用前未初始化這在訪問可能為空的指針時(shí)常見。misaligned stack access ARM64上更易觸發(fā)的棧訪問對(duì)齊錯(cuò)誤。failed to attach program 附加階段失敗可能是跟蹤點(diǎn)路徑錯(cuò)誤或權(quán)限不足。/sys/kernel/debug/tracing/trace_pipe是FTFtrace的輸出管道。如果你使用了bpf_printk()輔助函數(shù)注意僅限調(diào)試對(duì)性能有影響它的輸出會(huì)出現(xiàn)在這里而不是標(biāo)準(zhǔn)輸出。這是調(diào)試BPF程序邏輯的“printf大法”。4.4 第四步驗(yàn)證事件觸發(fā)與上下文訪問程序可能附加成功了但觸發(fā)條件不滿足或者訪問上下文數(shù)據(jù)時(shí)出錯(cuò)。事件是否觸發(fā)對(duì)于kprobe你可以用cat /sys/kernel/debug/tracing/kprobe_events查看已注冊的探針。對(duì)于tracepoint可以先用原生的Ftrace驗(yàn)證事件是否發(fā)生sudo echo 1 /sys/kernel/debug/tracing/events/syscalls/sys_enter_openat/enable然后查看trace_pipe。上下文訪問偏移量這是ARM64調(diào)試的重中之重。在系統(tǒng)調(diào)用跟蹤中參數(shù)保存在寄存器里。x86_64和ARM64的寄存器映射完全不同。例如獲取sys_enter_openat的第一個(gè)參數(shù)dfdx86_64:PT_REGS_PARM1(ctx)可能對(duì)應(yīng)rdi寄存器。ARM64: 需要查看內(nèi)核源碼arch/arm64/include/asm/syscall.h和arch/arm64/include/asm/ptrace.h。通常第一個(gè)參數(shù)在regs-regs[0]。絕對(duì)不要硬編碼偏移量。使用內(nèi)核頭文件提供的宏如PT_REGS_PARM1_CORE如果可用或者參考libbpf中bpf_tracing.h等頭文件的實(shí)現(xiàn)。一個(gè)常見的錯(cuò)誤是直接使用x86的偏移量宏導(dǎo)致在ARM64上讀到錯(cuò)誤的數(shù)據(jù)。5. 高級(jí)調(diào)試技術(shù)讓問題無所遁形當(dāng)基礎(chǔ)排查無效時(shí)需要?jiǎng)佑酶鼜?qiáng)大的工具。5.1 使用GDB調(diào)試用戶態(tài)加載器附BPF程序BPF程序本身在內(nèi)核運(yùn)行無法直接用GDB調(diào)試。但我們可以調(diào)試用戶態(tài)的加載器程序并在關(guān)鍵點(diǎn)如加載BPF程序前、后讀取映射時(shí)設(shè)置斷點(diǎn)觀察其行為。# 在ARM64設(shè)備上使用gdbserver如果設(shè)備資源緊張可在主機(jī)交叉調(diào)試 gdbserver :1234 ./your_user_loader # 在x86開發(fā)主機(jī)上使用交叉調(diào)試版本的gdb aarch64-linux-gnu-gdb ./your_user_loader (gdb) target remote arm-device-ip:1234 (gdb) break main (gdb) break bpf_prog_load (gdb) continue通過調(diào)試你可以確認(rèn)加載器是否成功打開并讀取了BPF目標(biāo)文件.o。調(diào)用bpf()系統(tǒng)調(diào)用或libbpf的bpf_object__load()時(shí)的返回值。錯(cuò)誤碼負(fù)值會(huì)告訴你具體原因如-EINVAL,-EACCES,-ENOENT。映射是否成功創(chuàng)建文件描述符fd是否有效。5.2 分析JIT編譯后的機(jī)器碼對(duì)于極端性能問題或驗(yàn)證器通過但行為異常的情況需要查看BPF字節(jié)碼被JIT編譯后的ARM64機(jī)器碼。bpftool prog dump jited id PROG_ID linumlinum選項(xiàng)會(huì)嘗試關(guān)聯(lián)源代碼行號(hào)如果編譯時(shí)帶了-g參數(shù)。這就像閱讀內(nèi)核為你的BPF程序生成的“最終執(zhí)行版本”。你可以看到內(nèi)存訪問指令ldr,str的地址計(jì)算是否正確。條件分支b.eq,b.ne是否跳轉(zhuǎn)到預(yù)期位置。輔助函數(shù)調(diào)用是否被正確轉(zhuǎn)換為bl指令到內(nèi)核 helper 函數(shù)。實(shí)操心得對(duì)比xlated驗(yàn)證器轉(zhuǎn)換后和jitedJIT編譯后的代碼有時(shí)能發(fā)現(xiàn)驚喜。我曾遇到一個(gè)案例驗(yàn)證器通過的代碼在JIT階段由于ARM64一個(gè)特殊的地址生成優(yōu)化導(dǎo)致對(duì)映射值的訪問偏移計(jì)算錯(cuò)誤。只有對(duì)比兩者才能定位。5.3 利用BPF自驗(yàn)證與模擬執(zhí)行較新版本的內(nèi)核和bpftool支持更強(qiáng)大的功能# 使用bpftool的prog load命令進(jìn)行“干跑”dry-run它會(huì)在不實(shí)際加載的情況下運(yùn)行驗(yàn)證器 bpftool prog load your_prog.o /sys/fs/bpf/dry_run type tracepoint \ attach_tracepoint:syscalls:sys_enter_openat dry-run # 檢查驗(yàn)證器的詳細(xì)日志通常dry-run失敗會(huì)給出更詳細(xì)的輸出 sudo dmesg | tail -100此外內(nèi)核的BPF驗(yàn)證器日志詳細(xì)程度可以通過sysctl控制sudo sysctl kernel.bpf_stats_enabled1 sudo sysctl kernel.bpf_verbose1 # 如果內(nèi)核支持輸出更詳細(xì)驗(yàn)證信息加載程序后查看/sys/kernel/debug/bpf/prog_id下的文件可能會(huì)獲得統(tǒng)計(jì)信息。6. ARM64特有的陷阱與最佳實(shí)踐根據(jù)實(shí)戰(zhàn)經(jīng)驗(yàn)我總結(jié)了幾條在ARM64上開發(fā)調(diào)試BPF程序時(shí)最容易踩坑的地方和應(yīng)對(duì)策略。6.1 結(jié)構(gòu)體填充與大小端處理的坑問題一個(gè)在x86上完美工作的BPF程序在ARM64上讀取網(wǎng)絡(luò)協(xié)議頭時(shí)某些字段的值總是錯(cuò)亂。根因與排查編譯器填充ARM64有更嚴(yán)格的對(duì)齊要求。編譯器可能在結(jié)構(gòu)體成員間插入填充字節(jié)padding。使用#pragma pack(1)或__attribute__((packed))可以強(qiáng)制單字節(jié)對(duì)齊但可能會(huì)影響性能且需確保內(nèi)核和用戶態(tài)結(jié)構(gòu)體定義一致。顯式字節(jié)序轉(zhuǎn)換永遠(yuǎn)不要假設(shè)。對(duì)于從網(wǎng)絡(luò)包中讀取的16位或32位字段如端口號(hào)、IP地址必須使用bpf_ntohs(),bpf_ntohl()等輔助函數(shù)進(jìn)行轉(zhuǎn)換。即使是本機(jī)數(shù)據(jù)在跨平臺(tái)共享映射時(shí)也最好約定使用一種明確的字節(jié)序如小端。最佳實(shí)踐在BPF程序的共享頭文件中為所有跨平臺(tái)的結(jié)構(gòu)體使用#include linux/types.h中的標(biāo)準(zhǔn)類型如__u16,__be32并明確注釋字節(jié)序。使用offsetof()宏來獲取成員偏移量而不是硬編碼數(shù)字。6.2 有限的?？臻g與寄存器壓力問題一個(gè)復(fù)雜的BPF程序在x86上通過驗(yàn)證在ARM64上卻因“程序太復(fù)雜”而被拒絕。根因BPF程序的?？臻g非常有限通常512字節(jié)且可用寄存器數(shù)量固定。ARM64的BPF JIT編譯器可能對(duì)寄存器的使用和 spills將寄存器內(nèi)容暫存到棧有不同的策略導(dǎo)致驗(yàn)證器判斷其復(fù)雜度超限。排查與解決使用bpftool prog dump xlated查看程序注意那些對(duì)棧幀fp進(jìn)行大量負(fù)偏移訪問的指令這通常意味著局部變量過多。簡化程序邏輯減少函數(shù)調(diào)用深度內(nèi)聯(lián)輔助函數(shù)調(diào)用本身不增加棧幀但復(fù)雜的表達(dá)式會(huì)。將大的數(shù)據(jù)結(jié)構(gòu)如查找表從棧上移到BPF映射中。檢查是否使用了大量BPF_MAXINSNS單程序最大指令數(shù)附近的指令。雖然上限相同但不同架構(gòu)JIT后的指令數(shù)可能不同。6.3 針對(duì)ARM64優(yōu)化編譯選項(xiàng)在編譯時(shí)可以傳遞一些針對(duì)ARM64的優(yōu)化參數(shù)有時(shí)能避免奇怪的問題。clang -O2 -g -target bpf -D__TARGET_ARCH_arm64 \ -mcpuv3 \ -I/path/to/headers \ -c prog.c -o prog.o-mcpuv3指定了BPF的CPU版本v3支持更多的指令如原子操作和更靈活的跳轉(zhuǎn)。使用較新的特性可能使驗(yàn)證器做出更優(yōu)的判斷。調(diào)試BPF程序尤其是在異構(gòu)的ARM64平臺(tái)上是一個(gè)結(jié)合了系統(tǒng)知識(shí)、工具使用和耐心推理的過程。它沒有銀彈但有一條清晰的路徑從理解環(huán)境差異開始搭建正確的編譯環(huán)境利用bpftool和內(nèi)核日志進(jìn)行系統(tǒng)化排查最后在必要時(shí)深入JIT代碼和用戶態(tài)調(diào)試。每一次靜默失敗的背后都可能是映射未讀、事件未觸發(fā)、偏移量錯(cuò)誤或字節(jié)序混淆這些“經(jīng)典”問題。掌握這套方法并積累針對(duì)ARM64的特定經(jīng)驗(yàn)?zāi)憔湍茏審?qiáng)大的BPF技術(shù)在更廣闊的硬件舞臺(tái)上可靠地運(yùn)行。