GitHubじゃ!Pythonじゃ!

GitHubからPython関係の優良リポジトリを探したかったのじゃー、でも英語は出来ないから日本語で読むのじゃー、英語社会世知辛いのじゃー

cyrus-and

gdb-dashboard – PythonでのGDBのモジュラービジュアルインタフェース

投稿日:

PythonでのGDBのモジュラービジュアルインタフェース

GDBダッシュボード

PythonでGDBのためのモジュラービジュアルインタフェース。

これは、スタンドアロンの単一ファイル.gdbinitとして提供されます.gdbinitこれは、プログラム実行中に最も関連性の高い情報を表示する設定可能なダッシュボードを可能にします。 その主な目的は、現在のプログラム状態を検査するために発行されたGDBコマンドの数を減らし、プログラマが代わりに制御フローに集中できるようにすることです。

インストール

あなたのホームディレクトリに.gdbinitを置くだけです:

wget -P ~ git.io/.gdbinit

特徴

  • 単一のGDB initファイル。

  • メインのGDBコンソールまたは外部ファイル/ TTYにダッシュボードを書き込みます。

  • ネイティブPython APIを使用したGDBとの相互作用。

  • 最も基本的なニーズ(ソースコード、アセンブリ、レジスタなど)に対応するためのいくつかのデフォルトモジュールが含まれています。

  • ユーザー定義のモジュールは、 Pythonクラスを拡張することで簡単に開発できます。

  • 追加の設定ファイル( GDBとPythonの両方)は~/.gdbinit.d/から読み込まれます。

  • 完全にスタイリング可能なユーザーインターフェイスと動的コマンドプロンプト。

  • Pygments Pythonライブラリを使用したオプションの構文強調表示。

  • GDBコマンドは再定義されていません。代わりに、すべての機能をメインdashboardコマンドのサブコマンドとして使用できます。

デフォルトのモジュール

バンドルされたデフォルトモジュールのリストに従います。 完全な構文については、GDBヘルプシステムを参照してください。

  • assemblyは、プログラムカウンタを囲む逆アセンブルされたコードが表示されます。 使用可能であれば、現在のステートメントを構成する命令がマークされます。

  • historyは、GDBの値履歴の最後のエントリをリストします。

  • memoryはメモリ領域を検査することを可能にする。

  • registersは、CPUのレジスタとその値が表示されます。

  • sourceはプログラムソースコードを表示します(利用可能な場合)。

  • stackは、関数名とファイルの場所(使用可能な場合)を含む現在のスタックトレースを表示します。 必要に応じて、フレームの引数とローカルをリストします。

  • threads現在使用可能なthreadsリストします。

  • expressionsはユーザーのexpressions監視します。

ダッシュボードの出力

デフォルトでは、ダッシュボードはGDB端末に表示されますが、ダッシュボードとモジュールの両方の-outputコマンドによってこの動作が変更される可能性があります。 モジュールの出力が指定されていない場合、グローバル出力が使用されます。

ダッシュボード全体を別の端末に表示する

メインターミナルをGDBコマンドとターゲットI / O専用に使用できるように、ダッシュボードを別のターミナルに移動すると便利です。

  1. 1つの端末でGDBを起動する。

  2. 別のターミナル(例えば、 tmuxペイン)を開き、 ttyコマンドでTTYを取得します(例: /dev/ttys001 、さまざまな理由で名前が異なる場合があります)。

  3. ダッシュボード出力を新しく作成した端末にリダイレクトするには、コマンドdashboard -output /dev/ttys001dashboard -output /dev/ttys001します。

  4. 通常どおりにデバッグします。

各モジュールを別々の端末に表示する

1つまたは複数のモジュールの出力を個々の端末に表示することもできます。 2つ以上のモジュールが同じ出力を共有する場合、それらはいつものように積み重ねられます。

  1. 1つの端末でGDBを起動する。

  2. 別の端末を開き、 ttyコマンドでTTYを取得します。

  3. モジュールを選択してsourcedashboard source -output /dev/ttys001コマンドを発行して、その出力を新しく作成した端末にリダイレクトします。

  4. 他のどのモジュールでも繰り返す。

  5. 通常どおりにデバッグします。

ダッシュボード全体をウェブブラウザで表示する

これをさらに進めると、 gettyを使用して補助端末としてWebブラウザを使用することができます。 もちろん、上述の方法を使用して、1つ以上のウェブブラウザインスタンスに個々のモジュールの出力を表示することもできる。

  1. 1つの端末でGDBを起動する。

  2. 別の端末を開き、 gotty sh -c 'tty; cat'を実行しgotty sh -c 'tty; cat' gotty sh -c 'tty; cat'

  3. Webブラウザを開き、 http://localhost:8080に移動し、TTYをメモします。

  4. ダッシュボード出力をWebブラウザにリダイレクトするには、コマンドdashboard -output /dev/ttys001dashboard -output /dev/ttys001します。

  5. 通常どおりにデバッグします。

コマンド

GDBのドキュメントはhelp dashboard入手できます。 どんなGDBコマンドと同様に、略語も可能です。したがって、 dadashなどはすべてdashboard解決されます。

ダッシュボード

これはルートコマンドで、ダッシュボードを手動で再表示するために使用されます。

dashboard -configuration [ <file> ]

現在の設定(レイアウト、スタイル、出力)を表示し、オプションで<file>書き込み<file> このコマンドを使用すると、ダッシュボードのライブを構成し、変更を永続的にすることができます。たとえば、次のようにします。

dashboard -configuration ~/.gdbinit.d/auto

ダッシュボード出力[ <file> ]

デフォルトでは、ダッシュボードはGDBコンソールに書き込まれますが、出力をファイルにリダイレクトすることも、別のターミナルにリダイレクトすることもできます。 ターゲットが有効なターミナルTTYの場合、その幅はダッシュボードをフォーマットするために使用されます。そうでない場合は、メインのGDBコンソールの幅に戻ります。

引数なしでは、この設定をデフォルトにリセットします。

ダッシュボード – 有効[オン|オフ]

ターゲットプログラムが停止するたびに、ダッシュボードの自動表示を有効または無効にします。 ダッシュボードはデフォルトで有効になっており、無効になっている場合でもdashboardで手動で表示できます。

ターゲットプログラムが実行状態を変更していなくても、たとえばプログラマが現在選択されているフレームをupまたはdownコマンドで切り替える場合などに、ダッシュボードを再描画すると便利な場合があります。 ユーザ定義のinitファイルにいくつかのGDBフックを設定することで、これを行うことができます 。例えば:

define hookpost-up
dashboard
end

define hookpost-down
dashboard
end

ダッシュボード – レイアウト[ <directive> …]

デフォルトでは、すべてのモジュールが有効にされ、アルファベット順にダッシュボードに配置されます。 モジュールの数が増えると、どのモジュールがダッシュボードの一部になるのか、どこにあるのかを決定することが重要になります。

各ディレクティブは[!]<module>形式になってい! が存在すると、対応するモジュールはデフォルトで無効になります。 ディレクティブの順序は、ダッシュボード内の表示順序を示します。 例えば:

dashboard -layout source !assembly stack

リストに表示されないモジュールは無効にされ、アルファベット順に最後の要素の後に配置されます。

引数なしで実行された場合、このコマンドは使用可能なすべてのモジュールを、ディレクティブのリストの後にモジュールの出力ファイルのステータスの形式でリストします。

ダッシュボードスタイル[ <name> [ <value> ]]

ダッシュボードのスタイル可能な属性へのアクセスを参照してください。 たとえば、プロンプトをより使い慣れたものに変更するには、次のようにします。

dashboard -style prompt '(gdb)'

引数はPythonリテラルとして解析され、適切な型に変換されます。

名前だけを指定すると、このコマンドは現在の値を表示しますが、引数を指定しないとすべての属性が出力されます。

モジュールのサブコマンド

すべてのモジュールは、イネーブルフラグをトグルしてダッシュボードを再表示するために使用される独自のサブコマンドdashboard <module>を追加します。

モジュールは、追加のサブコマンドを宣言することもできhelp dashboard <module>参照してください。

さらに2つの事前定義サブコマンド-style-outputます。

-スタイル

dashboard <module> -style指定可能な属性を宣言すると、コマンドdashboard <module> -styleが利用可能になります。 その機能はdashboard -styleコマンドと同等ですが、モジュールに適用されます。

-出力

同様に、 dashboard <module> -outputdashboard -styleコマンドを模倣しますが、より細かい操作を可能にします。

構成

~/.gdbinit.d/ファイルはアルファベット順に実行されますが、Pythonファイルに優先されます。 サブディレクトリがある場合、それらは再帰的に移動されます。 アイデアは、カスタムモジュール定義を構成自体から分離することです。

慣例により、 メインの設定ファイルは~/.gdbinit.d/~/.gdbinit.d/init )に置かれ、ダッシュボードのスタイルとモジュールの設定だけでなく、通常のGDBパラメータのチューニングにも使用できます。

もう一つの方法は、提供された.gdbinit変更をハードコードすることです。新しいモジュールとGDB設定を.gdbinit modulesと.gdbinit # Better GDB defaultsそれぞれ追加するだけです。

プロジェクトごとの構成

GDBはネイティブに.gdbinitファイルの自動ロードを.gdbinitますが、現在のプロジェクトタイプ(C ++開発、リバースエンジニアリングなど)に応じて異なるダッシュボードスタイルを設定すると便利です。 セキュリティ上の理由から、この機能はデフォルトで無効になっています。 ファイルシステムのどこにでも自動ロードを有効にするには、この行をメインの設定ファイルに追加します。

set auto-load safe-path /

スタイル属性

ダッシュボードとそのモジュールのアスペクトをカスタマイズするために使用できる多くの属性があります。 それらはGDBヘルプシステム内で文書化されています。 ダッシュボード自体に関係することについては、次のように連絡することができます。

help dashboard -style

一方、モジュールの場合:

help dashboard <module> -style

ANSIエスケープコード

色とテキストスタイルは、 ANSIエスケープコードを使用して指定します。 たとえば、スタイルを1;31設定すると、 ^[[1;31mが生成され、赤( 31 )と明るい( 1 )のテキストが表示されます。 ansi属性をFalse設定すると、ANSI出力を無効にできます(コマンドプロンプトには影響しません)。

シンタックスハイライト

ansi属性がTrue設定されている場合、 Pygments Pythonライブラリをモジュールで使用して、ソースコードの構文強調を提供することができます。

syntax_highlighting stylable属性は、使用するPygments スタイルを定義する文字列です。

使用可能なすべてのスタイルのリストは、(GDB自身から)入手できます:

python
from pygments.styles import get_all_styles as styles
for s in styles():
    print(s)
end

好きなスタイルを繰り返し実行してみると便利です( Returnを押して次のスタイルを試し、 Ctrl-Dと終了します)。

python
from pygments.styles import get_all_styles as styles
for s in styles():
    c = 'dashboard -style syntax_highlighting {!r}'.format(s)
    gdb.execute(c)
    print(c)
    input()
end

仕切り

仕切りは、基本的にオプションのラベル付きの端子幅の水平ラインです。 第1の分周器は、モジュールを分離するために使用されるものであり、第2の分周器は、モジュールの内部で使用され、異なるセクションを論理的に分離する。 セクションまたはモジュールが空の場合、ディバイダに使用されるスタイルはoff修飾子を持つスタイルです。

一般的なスタイル

これらは、便宜上定義され、デフォルトモジュール内で使用される汎用ANSIスタイルです。

  • style_selected_1
  • style_selected_2
  • style_low
  • style_high
  • style_error

カスタムモジュール

カスタムモジュールの考え方は、ターゲットプログラムステータスから読み取り専用情報にアクセスする方法を提供することです。 プログラムの実行中にのみ照会されると想定することは安全です。

カスタムモジュールは、 Dashboard.Moduleクラスを継承し、いくつかのメソッドを定義する必要があります。

  • labelは、ディバイダに表示されるモジュールラベルを返します。

  • linesは、モジュールコンテンツを形成する文字列のリストを返します。 モジュールがコンテンツを一時的に生成できないときは、空のリストを返す必要があります。 そのディバイダはoff修飾子付きのスタイルを使用します。

モジュールの名前は、クラス名によって自動的に取得されます。

モジュールは、初期化時に一度インスタンス化され、GDBセッション全体で保持されます。

必要に応じて、モジュールには、クラスのPythonドキュメントストリングを指定することによって、GDBヘルプシステムに表示される説明を含めることができます。

オプションで、モジュールは、 attributesメソッドを定義することによってスタイル可能な属性を定義することができattributesメソッドは、キーが属性名であり、値が別の辞書である辞書を返します。

  1. defaultは、この属性の初期値です。

  2. docはGDBヘルプシステムに現れるこの属性のドキュメントです。 このキーは省略できます。

  3. nameはPythonオブジェクトの属性の名前で、デフォルトはキー値です。

  4. typeはこの属性の型であり、引数として渡された値を適切な型に変換したり、例外を送出したりするために使用されます。 このキーのデフォルトはstr型です。

  5. checkは、強制的な値を受け入れ、値が制約を満たす場合はTrueを返し、そうでない場合はFalseを返すコントロールコールバックです。 このキーは省略可能です。省略した場合、チェックは実行されません。

必要に応じて、モジュールは、 commandsメソッドを定義することによってサブコマンドを宣言することができcommandsメソッドは、キーがコマンド名であり、値が別の辞書である辞書を返しcommands

  1. actionは実行されるコールバックで、GDBプロンプトから生の入力文字列を受け取ります。 コールバックは、メッセージが自動的にユーザーに表示される誤った状況を通知するために例外を発生させることがあります。

  2. docはコマンドのドキュメントです。

  3. completionは、 リファレンス・マニュアルで定義されているgdb.COMPLETE_*定数の1つである完了ポリシーです。 このキーはオプションで、デフォルトはNoneこれはgdb.COMPLETE_NONEと同等gdb.COMPLETE_NONE

共通の機能

多くの補助共通関数がグローバルスコープで定義されています。提供される.gdbinitあり、 ANSI出力、分割書式、変換コールバックなどのトピックがあります。多かれ少なかれ、バンドルされたデフォルトモジュール内にあります。

既定のモジュールは既に良い例ですが、ここでは新しいカスタムモジュールのテンプレートとして使用できる単純なモジュールがあり、デバッギングセッション中にプログラマーがテキストの一部を書き留めることができます。

class Notes(Dashboard.Module):
    """Simple user-defined notes."""

    def __init__(self):
        self.notes = []

    def label(self):
        return 'Notes'

    def lines(self, term_width, style_changed):
        out = []
        for note in self.notes:
            out.append(note)
            if self.divider:
                out.append(divider())
        return out[:-1] if self.divider else out

    def add(self, arg):
        if arg:
            self.notes.append(arg)
        else:
            raise Exception('Cannot add an empty note')

    def clear(self, arg):
        self.notes = []

    def commands(self):
        return {
            'add': {
                'action': self.add,
                'doc': 'Add a note.'
            },
            'clear': {
                'action': self.clear,
                'doc': 'Remove all the notes.'
            }
        }

    def attributes(self):
        return {
            'divider': {
                'doc': 'Divider visibility flag.',
                'default': True,
                'type': bool
            }
        }

上のコードをPythonファイルに保存するには、 ~/.gdbinit.d/内のnotes.pyと言って、次のコマンドを(ヘルプとともに)利用できます:

dashboard notes
dashboard notes add
dashboard notes clear
dashboard notes -style

最小要件

GDBダッシュボードでは、正しく動作するためにはPython 2.7でコンパイルされたGDB 7.7以上が必要です。

詳細や回避策については#1を参照してください。

追加のGDBフロントエンド

GDBダッシュボードは、TUI、Nemiver、QtCreatorなどの追加のフロントエンドとシームレスに動作するようにはなっていません。

これを回避するには基本的に2つの方法があります:

  • メインデバッグツールがGDBダッシュボードの場合、フロントエンドに.gdbinitファイルをロードさせないようにすることをお勧めします。通常、これにはオプションがあります。

  • それ以外の場合、GDBダッシュボードを手動でロードすることができます。つまり、通常どおりにインストールします。

     mv ~/.gdbinit ~/.gdb-dashboard
    

    最後に、必要に応じてGDBシェルからロードします。

     source ~/.gdb-dashboard
    

リソース

ライセンス

Copyright(c)2015-2018 Andrea Cardaci cyrus.and@gmail.com

本ソフトウェアおよび関連するドキュメンテーションファイル(以下「本ソフトウェア」といいます)のコピーを取得した者は、本ソフトウェアを制限なく使用、複製、改変、マージする権利を含むがこれに限定されるものではなく、本ソフトウェアのコピーを発行、配布、サブライセンス許諾、および/または販売すること、および本ソフトウェアが提供されている人に、以下の条件に従うことを許可すること。

上記の著作権表示およびこの許可通知は、本ソフトウェアのすべてのコピーまたは実質的な部分に含まれるものとします。

ソフトウェアは、いかなる保証もない、「AS IS」提供明示または黙示、特定の目的への適合性、および非侵害に対する市場性、適合性の保証を含むがこれらに限定されれていません。 作者または著作権者は、いかなる場合も、本ソフトウェアまたはその使用に関連して発生したものであっても、その使用に起因するものであっても、契約違反、その他の損害賠償その他の損害賠償の責任は負わないものとします。ソフトウェア。







-cyrus-and
-, ,

執筆者: