自分も驚嘆する#emacs#gdb#連動、これこそ最高のemacs-gdb

最近、android ndkの開発が進んでいるため、コマンドラインgdbと付き合わざるを得ません.eclipseはgdbまで遅すぎます.
emacsでgudでndk-gdbを操作するのはずっと不適切だと思います.だから退いてコマンドライン方式に変更しました.
bt(backtrace)コマンドで呼び出されたcall stackは、terminalのcopyからemacsまで再び表示されます.
この日は工夫を凝らし、define命令でこのcall stackを一度にemacsのbufferに表示しようとした.
defineは最良のgdb拡張方法ではありません.python gdb拡張インタフェースがあるからです.残念ながらteamのgdbの高人は私のコンパイルを手伝う暇がありません
with-pythonのgdb.
いくつかのinfoドキュメントを表示すると、巧みにloggingコマンドを使用して、gdbの内容をemacsに出力することができます.この簡単で奇妙で役に立つスクリプトは以下の通りです.

define gobt
  set logging file ~/.gdb.btt
  set logging overwrite on
  set logging redirect on
  set logging on
  bt
  set logging off
  shell echo \#Local Variables: \# >>  ~/.gdb.btt
  shell echo \#mode: compilation \# >>  ~/.gdb.btt
  shell echo \#End: \# >>  ~/.gdb.btt
  shell emacsclient -n ~/.gdb.btt
end

emacsのserverが起動すると、インタラクティブなcall stackが得られ、どの行で車を返すか、対応する呼び出し位置にジャンプしてコードを表示します.
もう1つのコマンドは簡単です.

define eb
  source ~/.gdb.line
end

その強さは、次のemacs lispと協力することです.

(defun jr-debug-line ()
  (interactive)
  (let ((fn buffer-file-name)
        (ln (line-number-at-pos)))
    (with-temp-buffer (insert (format "b %s:%d" fn ln))
                      (write-region (point-min) (point-max) "~/.gdb.line"))
    (kill-new (format "b %s:%d" fn ln))))
(global-set-key (kbd "C-c b") 'jr-debug-line)

これにより、emacsでファイルをブレークポイントすることができます.
最後の設定はEDITOR環境変数です.emacsでgdbの現在の行を表示するには、次のようにします.

export EDITOR="emacsclient -n "

この場合、ed(it)コマンドはgdbの現在のframeの現在の行に送信します.
半二重のデバッグ環境が完了しました.TUIのC-x C-aが足りない時、edは神器ですね.
P.S:上記gobtで生成したback traceは任意の場所に保存でき、いつでも現場を見ることができます.これはeclipseやintelijよりも強力です.