RFC-0178：每項工作有多個偵錯例外狀況管道

摘要

此 RFC 建議將 zx_task_create_exception_channel 變更為允許最多 32 個 才能對單一工作建立偵錯例外狀況管道

提振精神

Fuchsia 上的偵錯工具需要建立偵錯例外狀況管道，以便執行 系統就會啟動監控程序 立即附加在資源中偵錯例外狀況管道通常建立於 的根工作，以便偵錯工具能監控所有程序。

程序啟動時，核心會逐步瞭解 以便通知偵錯工作例外狀況管道。這趟旅程會從新的 持續升級，直到偵錯工作的例外狀況為止 或是已執行根工作

不過，目前的實作方式有兩項缺點。

• 一項工作最多只能有一個偵錯例外狀況管道，也就是 大多數的偵錯工具可以監控特定工作階層的任何子樹狀結構。
• 系統只會通知第一個找到的偵錯例外狀況管道，例如 子項工作上的偵錯工具無法觀察父項工作的偵錯工具

相關人員

講師：cpu@google.com

審查人員：brettw@google.com、maniscalco@google.com

諮詢：johngro@google.com

社會化：我們曾在 Fuchsia「核心演進工作」討論這個想法。 群組。

設計

我們建議 Zircon 允許單一工作執行多個偵錯工作例外狀況管道。

Zircon 有 5 種例外狀況管道： 偵錯工作、工作、偵錯程序、程序和執行緒。您可以逐一建立 相應物件最多一次這項限制設為避免 棘手情況，例如多個例外狀況處理常式會為 ZX_PROP_EXCEPTION_STATE。

但「偵錯工作」因為畫面上是通知專用 管道：可接收的唯一例外狀況類型為 ZX_EXCP_PROCESS_STARTING 系統會忽略 ZX_PROP_EXCEPTION_STATE。因此您可以 多項偵錯例外狀況管道 不一致的情況

在單一工作上建立多個偵錯工作例外狀況管道時， ZX_EXCP_PROCESS_STARTING事件將依序傳送至所有管道 讓多個事件監聽器檢查處理程序。限制 一項偵錯工具可以附加至指定程序，因為「debug」 程序」例外狀況管道仍專屬於您，除 第一個結果會是 ZX_ERR_ALREADY_BOUND。

此外，我們建議修改 ZX_EXCP_PROCESS_STARTING 事件，用來讓一個事件完全傳播 即使子項工作建立了例外狀況管道也一樣。偵錯 較低層級的工作例外狀況管道會收到通知 沒有在較高層級之前就先看到先前建立的頻道在任何層級 就會在隨後建立的頻道前收到通知這項程序會持續進行 僅在所有例外狀況管道收到通知和例外狀況物件時開始執行 都沒有問題

請注意，任何例外狀況訊息接收器都有可能的處理程序 不關閉例外狀況物件的控制代碼，就無限期啟動。 但是，它們無法立即停止處理程序。

實作

系統呼叫不會對 API 或 ABI 進行變更。現有的行為 「zx_task_create_exception_channel」將變更為允許存取 N 個頻道 ，而不是在第一個值之後傳回 ZX_ERR_ALREADY_BOUND。

成效

可能會封鎖更多事件監聽器，因此效能可能會降低 但不應使用偵錯例外狀況管道 ，或由長時間執行的程式持有。這是正常現象 僅適用於偵錯工具或類似的偵錯工具，因此影響程度不會太大。

一般而言，偵錯工具應立即關閉例外狀況控點 完成必要設定後

安全性考量

為了避免對核心遭受 DoS 攻擊，我們應限制 系統會針對一項工作建立偵錯工作例外狀況管道上限應該是比較大型的 足以允許任意數量的偵錯工具執行，例如 32。

測試

新的測試案例會新增至 //zircon/system/utest/debugger，以涵蓋這項資訊 而不是每個特徵的分數

說明文件

說明例外狀況處理和 zx_task_create_exception_channel 將成為 以反映變更

缺點、替代方案和未知

替代做法：使用者空間委派程序會從根工作開始

這個方法可避免變更核心。而是使用者空間委派項目 保存根工作偵錯管道並提供 FIDL 介面，可讓偵錯工具 即會啟動訂閱程序委派項目可以是元件管理員 目前為 fuchsia.kernel.RootJob 提供服務，或獨立計畫。

通訊協定如下所示

@discoverable
protocol RootJob {
    /// Hanging get pattern
    GetProcessStartingEvent() -> (resource struct {
        process zx.handle:PROCESS;
        continue zx.handle:EVENTPAIR;  // dropping this eventpair will propagate
                                       // the event to the next listener.
    }) error zx.status;
};

這種做法的問題

• 這只會套用至根工作。偵錯工具需要兩個邏輯才能執行根工作 和非根工作
• 在子項工作上建立的例外狀況管道可以停止事件傳播 到根目錄
• 如果導入 FIDL API 時使用的函數類似 syscall。

替代做法：debug_agent 支援多個用戶端

我們也能讓 debug_agent 支援多個用戶端來解決今日的問題。 亦即 debug_agent 會變成單例模式

問題在於

• 更多工作會參與其中。
• debug_agent 將成為 Fuchsia 的指定偵錯工具。其他偵錯工具 就必須與 debug_agent 通訊 存取 API