2.0.0-1.5.1 (2021年4月12日)
スタンドアロンのユーザー・スペース実装の5番目のエラータ。
これは、機能が制限されたプレリリースです。
新機能:
-
pidプロバイダが実装され、ユーザー・スペース・レベル(共有ライブラリおよび実行可能ファイル内)での関数境界トレースが有効になりました。今後の開発では、ここで提供される機能をユーザー・スペース・レベルでの任意の命令トレースで補強します。
-
ERRORプローブ(dtraceプロバイダ)が実装されています。ゼロによる除算やNULLポインタの間接参照などの一部のエラー状態は、BPFプログラムの実行で致命的な障害となるため、BPFプログラムで明示的にチェックされます。
-
正規化集積アクション(normalize()およびdenormalize())が実装されました。
-
8バイトを超えるサイズのグローバル変数とローカル変数、および参照による変数へのアクセスのサポートが追加されました。これには、最大256バイトのサイズの構造体割当て文を許可するなどが含まれます。今後の作業では、より大きな値サイズを使用できます。
-
BPF検証機能の出力ログの最大サイズを指定する-xbpflogsize=Nオプションが追加されました。このログは、BPFプログラムをカーネルにロードできない場合に生成されます。このオプションは、Dオプション・プラグマを使用して設定することもできます。
-
-Sオプションに対する-xdisasm=Nのサポートが改善されました。使用可能な逆アセンブリのリストが更新されました。<N>の値は、次の使用可能なリストの任意の数値の合計です。
-
1 =節の関数のコンパイルおよびアセンブリの後。
-
2 =プローブ・プログラムを構築した後。
-
4 =依存関係をプローブ・プログラムにリンクした後。
-
8 =すべての処理の後、プローブ・プログラムをロードする前。
-
パッケージの変更点:
-
UbuntuでDTraceを構築するためのサンプル・スクリプトが追加されました。
バグ修正:
-
様々な集積のバグ修正: 集積のリセット、書式設定されたprinta()、データのない集積を出力しない(集積ごとのラッチの使用)など。
-
ビットフィールド演算が、従来の動作(各ビットフィールドを次に大きい整数型のサイズに合わせる)を維持する方法で修正されました。
内部変更:
-
カーネル・トレースポイント・ベースのプロバイダの実装が、一貫性を高め、新しいpidプロバイダの実装のニーズに対応するように修正されました。pidプロバイダは、カーネル・プローブに1対1でマップしないプローブを公開するプロバイダを実装するためのサンプルも提供します。
-
デュアルコピー集積コードをオフにするメカニズムができました。このメカニズムは、より新しいカーネルに移行する場合に使用されると予想されます。しかし、当分は、単に過剰なBPFマップ領域を使用しているだけです。
-
eventfdメカニズムが、1つ以上のプロセスが終了したことを示すために使用される条件変数の置換として使用されます。つまり、プロセス終了通知がトレース・バッファ・データ通知とともに処理されます。dtrace_sleep()関数が非推奨となりました。
-
スタイルの一貫性を高めるためにソース・コードがリファクタリングされ、スタイル・ガイド(CODING-STYLE)が追加されました。
-
*_addおよび_del htab関数の標準実装が導入されました。
-
生成されたBPFコードのジャンプ・ターゲットの再配置が、ラベルのないBPF_NOP命令を処理するように修正されました。
-
3つ以上のカーネル・リリースで異なる定義を持つトランスレータを処理します。
-
プリコンパイル済BPF関数get_gvar()およびset_gvar()が削除されました。
テストスイートの変更:
-
新しいテストが追加されたか、新しい機能のためにXFAIL注釈が更新されました。
-
プローブがないときにライブラリの依存関係が何を意味するかに関して、未定義の動作に対する依存性を排除するために、test/unittest/pragma/*libdep*テストにプローブが追加されました。
-
集積テストが改善されています。
-
いくつかの逆アセンブリ・テストが追加されました。
既知の問題点:
-
一部のアーキテクチャ(aarch64など)は、JITでコンパイルされたBPFプログラムのハードコーディングされたメモリー量を確保します。各プログラムまたはサブプログラムは、メモリー内の全体のページ数を占有します。カーネルが大きなページサイズ(16kまたは64k)で構成されている場合、予約されたメモリー量が、大量のプローブの同時使用をサポートするのに十分ではない可能性があります。
予約メモリーはシステム全体であるため、同時DTraceトレース・セッションは、同じ制限されたページ・プールからメモリーを消費します。
現在、この問題の既知の回避策はありません。