Dev_tools

Nvim :help ページは、生成されたソース tree-sitter-vimdoc パーサーを使用して。

Nvim の開発のためのツールとテクニック

次のアドバイスは、Nvim 自体に関する問題の解決またはデバッグに役立ちます。

TODO: debug.txt をここにマージします。

バックトレース dev-tools-backtrace

LINUX

コアダンプは Ubuntu、CentOS、およびその他ではデフォルトで無効になっています。コアダンプを有効にするには

ulimit -c unlimited

systemd ベースのシステムでバックトレースを取得するのは

coredumpctl -1 gdb

coredumpctl はオプションのツールなので、インストールする必要がある場合があります

sudo apt install systemd-coredump

完全なバックトレースが最も役立ちます。クラッシュに関連するバグを報告する場合は、backtrace.txt ファイルを送信してください

2>&1 coredumpctl -1 gdb | tee -a backtrace.txt
(gdb) thread apply all bt full

coredumpctl のないシステムでは、現在のディレクトリまたは他の場所に core ダンプファイルが表示される場合があります。apport がインストールされている Linux システム（Ubuntu など）では、コアダンプファイルが保存されるディレクトリは、システム構成によって /var/lib/apport/coredump または他の場所になります（/proc/sys/kernel/core_pattern を参照）。https://stackoverflow.com/a/18368068 も参照してください。

./core ダンプファイルからバックトレースを取得するには

gdb build/bin/nvim ./core 2>&1 | tee backtrace.txt
(gdb) thread apply all bt full

MACOS

nvim がクラッシュした場合、バックトレースは Console.app（古い macOS バージョンの「Crash Reports」または「User Diagnostic Reports」）で確認できます。

open -a Console

macOS でコアダンプを有効にすることもできます。これを行うには、最初に /cores/ ディレクトリが存在し、書き込み可能であることを確認します

sudo mkdir /cores
sudo chown root:admin /cores
sudo chmod 1775 /cores

次に、コアサイズの上限を unlimited に設定します

ulimit -c unlimited

これはシェルプロセスごとに実行されることに注意してください。すべてのシェルでこれをデフォルトにする場合は、上記の行をシェルの初期化ファイル（~/.bashrc など）に追加します。

その後、コアファイルを lldb で開くことができます

lldb -c /cores/core.12345

Apple のドキュメントアーカイブには他にも役立つ情報がありますが（https://developer.apple.com/library/archive/technotes/tn2124/_index.html#//apple_ref/doc/uid/DTS10003391-CH1-SECCOREDUMPS,）、このページの一部の内容は古くなっています（たとえば、/etc/launchd.conf を使用してコアダンプを有効にするなど）。

Gdb dev-tools-gdb

機能テストをステップ実行するための GDB の使用

TEST_TAGを使用して、一致するバスタグ（#foo の形式、例: it("test #foo ...", ...)）のテストを実行します。

GDB=1 TEST_TAG=foo make functionaltest

次に、別の端末で

gdb build/bin/nvim
(gdb) target remote localhost:7777

-- https://github.com/neovim/neovim/blob/master/test/functional/testnvim.lua で nvim_argv を参照してください。

単体テストをステップ実行するための LLDB の使用

lldb .deps/usr/bin/luajit -- .deps/usr/bin/busted --lpath="./build/?.lua" test/unit/

GDB の使用

pid が 1234 の実行中の nvim プロセスにアタッチする場合（ヒント: 実行中の Nvim インスタンスの pid は getpid() を呼び出すことで取得できます）、次のようにします。

gdb -tui -p 1234 build/bin/nvim

gdb インタラクティブプロンプトが表示されます。いつでも

foo() 関数にブレークポイントを設定するには break foo

次のステートメントをステップオーバーするには n

最後のコマンドを繰り返すには <Enter>

次のステートメントにステップインするには s

続行するには c

現在の関数からステップアウトするには finish

zub の値を出力するには p zub

btを実行すると、現在のロケーションからのバックトレース（コールスタック）が表示されます。

CTRL-x CTRL-aまたはtui enableを実行すると、現在のデバッグコンテキストにおけるソースファイルのTUIビューが表示されます。これによりgdbの「フロントエンド」を使用する必要がなくなるため、非常に役立ちます。

<up>と<down>を押してソースファイルビューをスクロールします。

GDBリバースデバッグ

set record full insn-number-max unlimited

continueを少し実行します（少なくともmain()が実行されるまで）

record

バグを発生させた場合は、revert-next、reverse-stepなどに使用して、デバッガーを巻き戻します。

GDBSERVERを使用する

複数のgdbクライアントを同じ実行中のnvimプロセスに接続することも、ローカルのgdbを使用してリモートのnvimプロセスに接続することもできます。gdbserverを使用すると、単一のプロセスにアタッチして、複数のgdbクライアントから制御できます。

ターミナルを開き、次のようにnvimに接続されたgdbserverを起動します。

gdbserver :6666 build/bin/nvim 2> gdbserver.log

gdbserverはポート6666でリッスンしています。別のターミナルでこのデバッグセッションに接続する必要があります。

gdb build/bin/nvim

gdbを入力したら、リモートセッションに接続する必要があります。

(gdb) target remote localhost:6666

gdbserverがTUIをバックグラウンドプロセスとして配置した場合、TUIはptyからの入力（SIGTTIN信号を受信）や出力データ（SIGTTOU信号）を読み取れなくなる可能性があります。強制的にTUIをフォアグラウンドプロセスとして配置するには、次の行を追加できます。

signal (SIGTTOU, SIG_IGN);
if (!tcsetpgrp(data->input.in_fd, getpid())) {
    perror("tcsetpgrp failed");
}

tui.c:terminfo_start。

TMUXでGDBSERVERを使用する

上記で説明したgdbserverメソッドを使用してデバッグセッションをすばやく開始するために、カスタムメイクファイルhttps://github.com/neovim/neovim/blob/master/BUILD.md#custom-makefileを使用することを検討してください。この例local.mkは、`make debug`を入力するとデバッグセッションを作成します。

.PHONY: dbg-start dbg-attach debug build
build:
    @$(MAKE) nvim
dbg-start: build
    @tmux new-window -n 'dbg-neovim' 'gdbserver :6666 ./build/bin/nvim -D'
dbg-attach:
    @tmux new-window -n 'dbg-cgdb' 'cgdb -x gdb_start.sh ./build/bin/nvim'
debug: dbg-start dbg-attach

ここでは、gdb_start.shは、デバッガーが起動したときに呼び出されるgdbコマンドを含んでいます。dbg-startルールによって起動されたサーバーに接続する必要があります。以下に例を示します。

(gdb) target remote localhost:6666
(gdb) br main