讓自己也驚歎的#emacs##gdb#聯動,這才是最好的emacs-gdb
阿新 • • 發佈:2019-02-06
由於最近在做比較深入的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,在哪行拍回車就跳轉到相應的呼叫位置檢視程式碼。
另一個命令更簡單:
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強大。