如何與BPF子系統互動¶

本文件提供了關於 BPF 子系統各種工作流程的資訊，包括報告錯誤、提交補丁以及為穩定版核心排隊補丁。

有關提交補丁的通用資訊，請參閱提交補丁：將程式碼提交到核心的基本指南。本文件僅描述與 BPF 相關的額外細節。

報告錯誤 ¶

問：如何報告 BPF 核心程式碼的錯誤？¶

答：由於所有 BPF 核心開發以及 bpftool 和 iproute2 BPF 載入器的開發都透過 bpf 核心郵件列表進行，請將發現的任何 BPF 相關問題報告到以下郵件列表：

bpf@vger.kernel.org

這也可能包括與 XDP、BPF 跟蹤等相關的問題。

鑑於 netdev 流量很大，請同時將 BPF 維護者新增到抄送（Cc）列表（來自核心 MAINTAINERS 檔案）：

Alexei Starovoitov <ast@kernel.org>
Daniel Borkmann <daniel@iogearbox.net>

如果已經確定了有問題的提交，請務必在報告中也將實際的提交作者新增到抄送列表。通常可以透過核心的 Git 倉庫識別他們。

請勿將 BPF 問題報告到 bugzilla.kernel.org，因為這幾乎可以保證報告的問題會被忽視。

提交補丁 ¶

問：在傳送更改進行審查之前，如何對我的更改執行 BPF CI？¶

答：BPF CI 基於 GitHub 並託管在 https://github.com/kernel-patches/bpf。雖然 GitHub 也提供了可用於實現相同結果的 CLI，但這裡我們專注於基於 UI 的工作流程。

以下步驟說明如何為您的補丁啟動 CI 執行：

在您自己的賬戶中建立上述倉庫的 fork（一次性操作）
在本地克隆 fork，檢出跟蹤 bpf-next 或 bpf 分支的新分支，並在其之上應用您要測試的補丁。
將本地分支推送到您的 fork，並分別針對 kernel-patches/bpf 的 bpf-next_base 或 bpf_base 分支建立拉取請求。

拉取請求建立後不久，CI 工作流程將執行。請注意，容量與上游提交的正在檢查的補丁共享，因此根據利用率，執行可能需要一段時間才能完成。

此外請注意，兩個基礎分支（bpf-next_base 和 bpf_base）將隨著補丁被推送到其跟蹤的相應上游分支而更新。因此，您的補丁集也將自動（嘗試）進行 rebase。此行為可能導致 CI 執行中止並以新的基線重新開始。

問：我需要將 BPF 補丁提交到哪個郵件列表？¶

答：請將您的 BPF 補丁提交到 bpf 核心郵件列表：

bpf@vger.kernel.org

如果您的補丁在多個不同的子系統（例如，網路、跟蹤、安全等）中有更改，請務必抄送相關的核心郵件列表和維護者，以便他們能夠審查這些更改併為補丁提供 Acked-by 簽名。

問：在哪裡可以找到 BPF 子系統當前正在討論的補丁？¶

答：所有抄送給 netdev 的補丁都在 netdev patchwork 專案下排隊等待審查：

https://patchwork.kernel.org/project/netdevbpf/list/

那些針對 BPF 的補丁，被分配給“bpf”委託人，由 BPF 維護者進一步處理。當前正在審查的補丁佇列可在以下連結找到：

https://patchwork.kernel.org/project/netdevbpf/list/?delegate=121173

一旦補丁經過整個 BPF 社群的審查並獲得 BPF 維護者的批准，它們在 patchwork 中的狀態將更改為“Accepted”（已接受），並且提交者將透過郵件收到通知。這意味著這些補丁從 BPF 的角度來看是好的，並且已被應用於兩個 BPF 核心分支之一。

如果社群的反饋需要重新提交補丁，它們在 patchwork 中的狀態將設定為“Changes Requested”（請求更改），並從當前審查佇列中清除。同樣適用於補丁被拒絕或不適用於 BPF 分支（但已分配給“bpf”委託人）的情況。

問：這些更改是如何進入 Linux 的？¶

答：有兩個 BPF 核心分支（Git 倉庫）。一旦補丁被 BPF 維護者接受，它們將被應用於這兩個 BPF 分支中的一個：

https://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf.git/

https://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf-next.git/

bpf 分支本身僅用於修復，而 bpf-next 則用於新功能、清理或其他型別的改進（“next-like”內容）。這類似於網路子系統的 net 和 net-next 分支。bpf 和 bpf-next 都將只有一個 master 分支，以簡化補丁應該 rebase 到哪個分支的問題。

bpf 分支中累積的 BPF 補丁將定期被拉取到 net 核心分支。同樣，bpf-next 分支中接受的累積 BPF 補丁將進入 net-next 分支。net 和 net-next 都由 David S. Miller 管理。從那裡，它們將進入 Linus Torvalds 管理的核心主線分支。要了解 net 和 net-next 合併到主線分支的過程，請參閱 netdev 子系統的文件：網路子系統 (netdev)。

偶爾，為了防止合併衝突，我們可能會向其他分支（例如跟蹤）傳送包含一小部分補丁的拉取請求，但 net 和 net-next 始終是主要的整合目標分支。

拉取請求將包含累積補丁的高階摘要，並且可以透過以下主題行在 netdev 核心郵件列表中搜索（yyyy-mm-dd 是拉取請求的日期）：

pull-request: bpf yyyy-mm-dd
pull-request: bpf-next yyyy-mm-dd

問：我如何指明我的補丁應該應用於哪個分支（bpf 還是 bpf-next）？¶

答：此過程與 netdev 子系統文件中描述的完全相同，請參閱網路子系統 (netdev)。主題行必須指明補丁是修復還是“next-like”內容，以便維護者知道它是針對 bpf 還是 bpf-next。

對於最終將進入 bpf -> net 分支的修復，主題必須如下所示：

git format-patch --subject-prefix='PATCH bpf' start..finish

對於最終將進入 bpf-next -> net-next 的功能/改進等，主題必須如下所示：

git format-patch --subject-prefix='PATCH bpf-next' start..finish

如果不確定補丁或補丁系列是直接進入 bpf 或 net，還是直接進入 bpf-next 或 net-next，即使主題行註明目標是 net 或 net-next 也沒有問題。最終由維護者決定補丁的委派。

如果明確補丁應該進入 bpf 或 bpf-next 分支，請務必針對這些分支 rebase 補丁，以減少潛在衝突。

如果補丁或補丁系列需要返工並在第二次或後續修訂中再次傳送，則還要求在主題字首中新增版本號（v2, v3, ...）：

git format-patch --subject-prefix='PATCH bpf-next v2' start..finish

當對補丁系列提出更改請求時，請始終重新發送整個補丁系列，幷包含反饋（切勿在舊系列之上傳送單獨的 diff）。

問：補丁被應用於 bpf 或 bpf-next 分支意味著什麼？¶

答：這意味著從 BPF 的角度來看，該補丁適合包含到主線中。

請注意，這並非最終裁決，補丁最終不一定會自動被 net 或 net-next 分支接受。

在 bpf 核心郵件列表中，審查可能隨時進行。如果圍繞某個補丁的討論得出結論，認為它無法按原樣包含，我們將要麼應用後續修復，要麼將其從分支中完全刪除。因此，我們還保留在必要時 rebase 分支的權利。畢竟，分支的目的是：

累積並暫存 BPF 補丁，以便整合到 net 和 net-next 等分支中，並且
在補丁進一步處理之前，對其執行廣泛的 BPF 測試套件和工作負載。

一旦 BPF 拉取請求被 David S. Miller 接受，那麼這些補丁將分別進入 net 或 net-next 分支，並從那裡進一步進入主線。再次強調，請參閱 netdev 子系統的文件網路子系統 (netdev) 以獲取更多資訊，例如它們多久合併到主線一次。

問：我需要等待多長時間才能收到 BPF 補丁的反饋？¶

答：我們儘量保持低延遲。通常的反饋時間約為 2 或 3 個工作日。這可能因更改的複雜性和當前補丁負載而異。

問：你們多久向 net 或 net-next 等主要核心分支傳送拉取請求？¶

答：為了避免 bpf 或 bpf-next 中累積過多的補丁，拉取請求會相當頻繁地傳送。

通常來說，預計每個分支的拉取請求會在週末定期傳送。在某些情況下，根據當前的補丁負載或緊急程度，拉取請求也可能在週中發出。

問：在合併視窗開放時，補丁會應用於 bpf-next 嗎？¶

答：在合併視窗開放期間，bpf-next 將不會被處理。這大致類似於 net-next 的補丁處理方式，因此請隨意查閱 netdev 文件網路子系統 (netdev) 以獲取更多細節。

在合併視窗開放的兩週內，我們可能會要求您在 bpf-next 再次開放時重新發送您的補丁系列。一旦 Linus 在合併視窗結束後釋出了 v*-rc1，我們將繼續處理 bpf-next。

對於未訂閱核心郵件列表的使用者，David S. Miller 在 net-next 上也運行了一個狀態頁面，提供指導：

http://vger.kernel.org/~davem/net-next.html

問：驗證器更改和測試用例 ¶

問：我更改了 BPF 驗證器，需要為 BPF 核心 selftests 新增測試用例嗎？

答：如果補丁更改了驗證器的行為，那麼是的，絕對有必要為 BPF 核心 selftests 套件新增測試用例。如果它們不存在且我們認為需要它們，那麼我們可能會在接受任何更改之前要求提供。

特別是，test_verifier.c 跟蹤了大量的 BPF 測試用例，包括 LLVM BPF 後端可能從受限的 C 程式碼中生成的許多邊緣情況。因此，新增測試用例對於確保未來的更改不會意外影響之前的用例至關重要。因此，請將這些測試用例視為：test_verifier.c 中未跟蹤的驗證器行為可能會發生變化。

問：samples/bpf 與 selftests 的選擇？¶

問：何時應該將程式碼新增到 samples/bpf/，何時新增到 BPF 核心 selftests？

答：通常，我們傾向於將程式碼新增到 BPF 核心 selftests，而不是 samples/bpf/。理由很簡單：核心 selftests 會定期由各種機器人執行，以測試核心迴歸。

我們新增到 BPF selftests 的測試用例越多，覆蓋率就越好，它們意外損壞的可能性就越小。這並不是說 BPF 核心 selftests 不能演示如何使用特定功能。

話雖如此，samples/bpf/ 可能是人們入門的好地方，因此建議將簡單功能的演示程式碼放入 samples/bpf/，但高階功能和邊緣情況測試則應放入核心 selftests。

如果您的示例看起來像一個測試用例，那麼請選擇 BPF 核心 selftests！

問：何時應該將程式碼新增到 bpftool？¶

答：bpftool（位於 tools/bpf/bpftool/ 下）的主要目的是提供一箇中央使用者空間工具，用於除錯和內省核心中活躍的 BPF 程式和對映。如果與 BPF 相關的 UAPI 更改允許轉儲程式或對映的額外資訊，那麼 bpftool 也應該擴充套件以支援轉儲它們。

問：何時應該將程式碼新增到 iproute2 的 BPF 載入器？¶

答：對於與 XDP 或 tc 層（例如 cls_bpf）相關的 UAPI 更改，約定是這些控制路徑相關的更改也從使用者空間側新增到 iproute2 的 BPF 載入器中。這不僅有助於正確設計 UAPI 更改以使其可用，而且還能使這些更改可供主要下游發行版更廣泛的使用者使用。

問：你們也接受 iproute2 的 BPF 載入器的補丁嗎？¶

答：iproute2 的 BPF 載入器的補丁必須傳送到：

netdev@vger.kernel.org

雖然這些補丁不由 BPF 核心維護者處理，但請務必將他們也新增到抄送列表，以便他們進行審查。

iproute2 的官方 Git 倉庫由 Stephen Hemminger 執行，可在以下連結找到：

https://git.kernel.org/pub/scm/linux/kernel/git/shemminger/iproute2.git/

補丁的主題字首需要是“[PATCH iproute2 master]”或“[PATCH iproute2 net-next]”。“master”或“net-next”描述了補丁應該應用到的目標分支。這意味著，如果核心更改進入了 net-next 核心分支，那麼相關的 iproute2 更改需要進入 iproute2 net-next 分支，否則它們可以針對 master 分支。iproute2 net-next 分支將在 master 中當前的 iproute2 版本釋出後合併到 master 分支。

與 BPF 類似，這些補丁最終會進入 netdev 專案下的 patchwork，並委託給“shemminger”進行進一步處理：

http://patchwork.ozlabs.org/project/netdev/list/?delegate=389

問：在提交 BPF 補丁之前，最低要求是什麼？¶

答：提交補丁時，請務必花時間並在提交之前充分測試您的補丁。切勿急於提交！如果維護者發現您的補丁沒有經過充分測試，這很容易讓他們不高興。測試補丁提交是一項硬性要求！

請注意，進入 bpf 分支的修復必須包含 Fixes: 標籤。這同樣適用於目標為 bpf-next 的修復，其中受影響的提交在 net-next（或某些情況下在 bpf-next）中。Fixes: 標籤對於識別後續提交至關重要，並且對需要進行反向移植的人員有巨大幫助，因此它是必不可少的！

我們也不接受提交資訊為空的補丁。請花時間認真編寫高質量的提交資訊，這至關重要！

這樣想：一個月後檢視您的程式碼的其他開發人員需要理解為什麼某個更改會以這種方式完成，以及原始作者的分析或假設是否存在缺陷。因此，提供適當的理由並描述更改的用例是必須的。

包含多個補丁的提交必須附有封面信，其中包含對系列的高階描述。BPF 維護者隨後會將此高階摘要放入合併提交中，以便將來從 Git 日誌中也能查閱。

問：涉及 BPF JIT 和/或 LLVM 更改的功能 ¶

問：當我新增新的指令或功能，同時需要 BPF JIT 和/或 LLVM 整合時，我需要考慮什麼？

答：我們努力保持所有 BPF JIT 最新，以確保在不同架構上執行 BPF 程式時能獲得相同的使用者體驗，並且在核心 BPF JIT 啟用時，程式不會回退到效率較低的直譯器。

如果您無法為特定架構實現或測試所需的 JIT 更改，請與相關的 BPF JIT 開發人員合作，以便及時實現該功能。請參閱 Git 日誌（arch/*/net/）以找到需要幫助的人。

此外，請務必為新指令新增 BPF 測試用例（例如 test_bpf.c 和 test_verifier.c），以便它們能夠獲得廣泛的測試覆蓋，並有助於執行時測試各種 BPF JIT。

如果出現新的 BPF 指令，一旦更改被 Linux 核心接受，請在 LLVM 的 BPF 後端中實現支援。有關詳細資訊，請參閱下面的 LLVM 部分。

問：“BPF_INTERNAL”符號名稱空間的作用是什麼？¶

答：匯出為 BPF_INTERNAL 的符號只能由 BPF 基礎設施使用，例如帶有輕量骨架的預載入核心模組。BPF_INTERNAL 之外的大多數符號也不期望被 BPF 外部的程式碼使用。符號可能缺乏此指定，因為它們早於名稱空間，或者由於疏忽。

穩定版提交 ¶

問：我需要在穩定版核心中包含某個特定的 BPF 提交。我該怎麼做？¶

答：如果您需要在穩定版核心中包含某個特定的修復，請首先檢查該提交是否已應用於相關的 linux-*.y 分支：

https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git/

如果尚未應用，請傳送電子郵件給 BPF 維護者，並將 netdev 核心郵件列表新增到抄送，請求將該修復排隊。

netdev@vger.kernel.org

總的來說，該過程與 netdev 本身相同，另請參閱網路子系統的文件：網路子系統 (netdev)。

問：你們也向當前未作為穩定版維護的核心進行反向移植嗎？¶

答：不。如果您需要在當前未由穩定版維護者維護的核心中包含某個特定的 BPF 提交，那麼您需要自行處理。

當前的穩定版和長期穩定版核心都列在此處：

https://kernel.linux.club.tw/

問：我即將提交的 BPF 補丁也需要進入穩定版 ¶

我該怎麼做？

答：與一般的 netdev 補丁提交規則相同，請參閱 netdev 文件網路子系統 (netdev)。

切勿在補丁描述中新增“Cc: stable@vger.kernel.org”，而是請求 BPF 維護者將補丁排隊。這可以透過在補丁的 --- 部分下方添加註釋來完成，該註釋不會進入 Git 日誌。或者，也可以透過簡單的郵件請求來完成。

問：穩定版補丁佇列 ¶

問：在哪裡可以找到當前已排隊等待提交到穩定版的 BPF 補丁？

答：一旦修復關鍵錯誤的補丁被應用到 bpf 分支，它們就會在以下連結排隊等待提交到穩定版：

http://patchwork.ozlabs.org/bundle/bpf/stable/?state=*

它們將至少在那裡等待，直到相關提交進入主線核心分支。

在獲得更廣泛的關注後，排隊的補丁將由 BPF 維護者提交給穩定版維護者。

測試補丁 ¶

問：如何執行 BPF selftests ¶

答：啟動到新編譯的核心後，導航到 BPF selftests 套件以測試 BPF 功能（當前工作目錄指向克隆的 Git 倉庫的根目錄）：

$ cd tools/testing/selftests/bpf/
$ make

要執行驗證器測試：

$ sudo ./test_verifier

驗證器測試會打印出所有當前正在執行的檢查。執行所有測試結束時的摘要將轉儲測試成功和失敗的資訊。

Summary: 418 PASSED, 0 FAILED

為了執行所有 BPF selftests，需要以下命令：

$ sudo make run_tests

有關詳細資訊，請參閱核心 selftest 文件。

為了最大化透過的測試數量，被測核心的 .config 應儘可能與 tools/testing/selftests/bpf 中的配置檔案片段匹配。

最後，為確保支援最新的 BPF 型別格式（BTF）功能——BPF 型別格式 (BTF) 中討論——對於使用 CONFIG_DEBUG_INFO_BTF=y 構建的核心，需要 pahole 1.16 版本。pahole 隨 dwarves 軟體包提供，也可從以下原始碼構建：

https://github.com/acmel/dwarves

pahole 在 commit 21507cd3e97b（“pahole: add libbpf as submodule under lib/bpf”）之後，從 v1.13 版本開始使用 libbpf 的定義和 API。它與 Git 倉庫配合良好，因為 libbpf 子模組會使用“git submodule update --init --recursive”進行更新。

不幸的是，預設的 GitHub 釋出原始碼不包含 libbpf 子模組原始碼，這將導致構建問題。來自 https://git.kernel.org/pub/scm/devel/pahole/pahole.git/ 的 tarball 與 GitHub 相同。您可以從以下連結獲取包含相應 libbpf 子模組程式碼的原始碼 tarball：

https://fedorapeople.org/~acme/dwarves

一些發行版已經打包了 pahole 1.16 版本，例如 Fedora、Gentoo。

LLVM 的靜態編譯器透過 llc --version 列出支援的目標，請確保 BPF 目標已列出。例如：

$ llc --version
LLVM (http://llvm.org/):
  LLVM version 10.0.0
  Optimized build.
  Default target: x86_64-unknown-linux-gnu
  Host CPU: skylake

  Registered Targets:
    aarch64    - AArch64 (little endian)
    bpf        - BPF (host endian)
    bpfeb      - BPF (big endian)
    bpfel      - BPF (little endian)
    x86        - 32-bit X86: Pentium-Pro and above
    x86-64     - 64-bit X86: EM64T and AMD64

為了利用 LLVM BPF 後端中新增的最新功能，開發人員建議執行最新的 LLVM 版本。對新的 BPF 核心功能（例如 BPF 指令集的新增）的支援通常是同時開發的。

所有 LLVM 版本都可以在以下網址找到：http://releases.llvm.org/

問：明白了，那麼如何手動構建 LLVM 呢？¶

答：我們建議希望獲得最快增量構建的開發人員使用 Ninja 構建系統，您可以在系統的包管理器中找到它，通常軟體包名稱是 ninja 或 ninja-build。

您需要 ninja、cmake 和 gcc-c++ 作為 LLVM 的構建必備條件。設定好這些後，繼續從 Git 倉庫構建最新的 LLVM 和 clang 版本：

$ git clone https://github.com/llvm/llvm-project.git
$ mkdir -p llvm-project/llvm/build
$ cd llvm-project/llvm/build
$ cmake .. -G "Ninja" -DLLVM_TARGETS_TO_BUILD="BPF;X86" \
           -DLLVM_ENABLE_PROJECTS="clang"    \
           -DCMAKE_BUILD_TYPE=Release        \
           -DLLVM_BUILD_RUNTIME=OFF
$ ninja

構建好的二進位制檔案可以在 build/bin/ 目錄中找到，您可以將 PATH 變數指向該目錄。

將 -DLLVM_TARGETS_TO_BUILD 設定為您希望構建的目標，您可以在 llvm-project/llvm/lib/Target 目錄中找到完整的目標列表。

問：報告 LLVM BPF 問題 ¶

問：我是否應該通知 BPF 核心維護者關於 LLVM BPF 程式碼生成後端中的問題，或者驗證器拒絕接受的 LLVM 生成程式碼的問題？

答：是的，請務必這樣做！

LLVM 的 BPF 後端是整個 BPF 基礎設施的關鍵部分，它與核心側的程式驗證緊密相連。因此，無論哪一方出現問題，都需要在必要時進行調查和修復。

因此，請務必在 netdev 核心郵件列表中提出這些問題，並抄送（Cc）BPF 維護者以處理 LLVM 和核心相關部分：

Yonghong Song <yhs@fb.com>
Alexei Starovoitov <ast@kernel.org>
Daniel Borkmann <daniel@iogearbox.net>

LLVM 還有一個問題追蹤器，可以在其中找到與 BPF 相關的錯誤：

https://bugs.llvm.org/buglist.cgi?quicksearch=bpf

然而，最好透過郵件列表聯絡，並將維護者新增到抄送列表。

問：核心和 LLVM 的新 BPF 指令 ¶

問：我已經向核心添加了一個新的 BPF 指令，如何將其整合到 LLVM 中？

答：LLVM 為 BPF 後端提供了一個 -mcpu 選擇器，以便允許選擇 BPF 指令集擴充套件。預設情況下，使用 generic 處理器目標，這是 BPF 的基本指令集（v1）。

LLVM 有一個選項可以設定為 -mcpu=probe，它將探測主機核心以獲取支援的 BPF 指令集擴充套件並自動選擇最優集合。

對於交叉編譯，也可以手動選擇特定版本。

$ llc -march bpf -mcpu=help
Available CPUs for this target:

  generic - Select the generic processor.
  probe   - Select the probe processor.
  v1      - Select the v1 processor.
  v2      - Select the v2 processor.
[...]

新新增到 Linux 核心的 BPF 指令需要遵循相同的方案，即提升指令集版本並實現對擴充套件的探測，以便使用 -mcpu=probe 的使用者在升級核心時可以透明地受益於最佳化。

如果您無法為新新增的 BPF 指令實現支援，請聯絡 BPF 開發人員尋求幫助。

順便說一句，BPF 核心 selftests 使用 -mcpu=probe 執行以獲得更好的測試覆蓋率。

問：用於目標 bpf 的 clang 標誌？¶

問：在某些情況下使用 clang 標誌 --target=bpf，而在其他情況下則使用與底層架構匹配的預設 clang 目標。它們之間有什麼區別？我何時應該使用哪一個？

答：儘管 LLVM IR 的生成和最佳化試圖保持與架構無關，但 --target=<arch> 仍然對生成的程式碼有一定影響：

BPF 程式可能會遞迴包含帶有檔案範圍內聯彙編程式碼的標頭檔案。預設目標可以很好地處理這種情況，而 bpf 目標可能會失敗，如果 bpf 後端彙編器不理解這些彙編程式碼（在大多數情況下是這樣）。
在不帶 -g 編譯時，使用預設目標編譯的 ELF 物件檔案中可能會存在額外的 ELF 段，例如 .eh_frame 和 .rela.eh_frame，但使用 bpf 目標則不會。
預設目標可能會將 C 語言的 switch 語句轉換為跳轉表查詢和跳轉操作。由於跳轉表放置在全域性只讀段中，BPF 程式將無法載入。bpf 目標不支援跳轉表最佳化。可以使用 clang 選項 -fno-jump-tables 來停用跳轉表生成。
對於 clang --target=bpf，可以保證指標或 long / unsigned long 型別始終具有 64 位寬度，無論底層的 clang 二進位制檔案或預設目標（或核心）是 32 位還是 64 位。然而，當使用原生 clang 目標時，它會根據底層架構的約定編譯這些型別，這意味著在 32 位架構的情況下，BPF 上下文結構中的指標或 long / unsigned long 型別將具有 32 位寬度，而 BPF LLVM 後端仍然以 64 位執行。原生目標主要在跟蹤中用於遍歷 pt_regs 或其他 CPU 暫存器寬度重要的核心結構。否則，通常推薦使用 clang --target=bpf。

您應該在以下情況下使用預設目標：

您的程式包含一個頭檔案，例如 ptrace.h，該標頭檔案最終會引入一些包含檔案範圍主機彙編程式碼的標頭檔案。
您可以新增 -fno-jump-tables 來解決跳轉表問題。

否則，您可以使用 bpf 目標。此外，在以下情況下，您必須使用 bpf 目標：

您的程式使用指標或 long / unsigned long 型別的、與 BPF 助手或上下文資料結構互動的資料結構。對這些結構的訪問由 BPF 驗證器驗證，如果原生架構與 BPF 架構（例如 64 位）不一致，可能會導致驗證失敗。例如，BPF_PROG_TYPE_SK_MSG 要求使用 --target=bpf。

祝您 BPF 程式設計愉快！

Linux 核心

目錄

本頁