emacs gud 中的 lldb 不更新 'up' 的源文件
lldb in emacs gud does not update source files for 'up'
我用过https://opensource.apple.com/source/lldb/lldb-69/utils/emacs/gud.el and https://github.com/ptrv/emacs.d/blob/master/site-lisp/gud-lldb.el
,以及 LLVM 3.9.1 中的 emacs 24.3 和 lldb。它可以在断点处停止,并在单独的 emacs window 中将光标显示在正确的源文件处。但是 lldb 中的 'up'/'down' 命令仅在 lldb emacs window 中显示新的源代码。没有显示新源代码的新 emacs window。
's'/'fin' 可以在不同的 windows.
中显示正确的代码
这是预期的吗?
我在 emacs 25.3.1 中使用 https://github.com/ptrv/emacs.d/blob/master/site-lisp/gud-lldb.el 运气更好。它还具有不尝试修补 gud.el 的优点。我是一个更独立的解决方案。上下移动堆栈帧时也无法移动光标,但通过此更改它可以工作:
*** gud-lldb.el.orig 2017-12-11 17:22:08.000000000 -0700
--- gud-lldb.el 2017-11-18 11:52:55.000000000 -0700
***************
*** 64,73 ****
;; * thread #1: tid = 0x2e03, 0x0000000100000de8 a.out`c + 7 at main.c:39, stop reason = breakpoint 1.1, queue = com.apple.main-thread
(string-match " at \([^:\n]*\):\([0-9]*\), stop reason = .*\n"
gud-marker-acc start)
! ;; (lldb) frame select -r 1
! ;; frame #1: 0x0000000100000e09 a.out`main + 25 at main.c:44
! (string-match "^[ ]*frame.* at \([^:\n]*\):\([0-9]*\)\n"
! gud-marker-acc start))
;(message "gud-marker-acc matches our pattern....")
(setq gud-last-frame
(cons (match-string 1 gud-marker-acc)
--- 70,79 ----
;; * thread #1: tid = 0x2e03, 0x0000000100000de8 a.out`c + 7 at main.c:39, stop reason = breakpoint 1.1, queue = com.apple.main-thread
(string-match " at \([^:\n]*\):\([0-9]*\), stop reason = .*\n"
gud-marker-acc start)
! ;; cherry
! ;; (lldb) frame #1: 0x000000010013e29a sta`sta::PathEnumFaninVisitor::visitFromToPath(sta::Pin const*, sta::Vertex*, sta::TransRiseFall const*, sta::Tag*, sta::PathVertex*, sta::Edge*, sta::TimingArc*, float, sta::Vertex*, sta::TransRiseFall const*, sta::Tag*, float&, sta::MinMax const*, sta::PathAnalysisPt const*) + 986 at /Users/foobar/File.cc:348
! (string-match "^.*frame.* at \([^:\n]*\):\([0-9]*\)\n"
! gud-marker-acc start))
;(message "gud-marker-acc matches our pattern....")
(setq gud-last-frame
(cons (match-string 1 gud-marker-acc)
jjcherry56,您的更改有效。而且,既然你找到了,我就把之前的答案从 -1 投票给 0。
所以,我查看了那个增量,最后明确地做了一个小改动。
特别是,我改变了模式的一部分:
string-match "^[ ]*frame
至
string-match "^.*frame
成功了!
无可否认,gud-lldb.el、^[ ]*frame 中的 "before" 模式(来自 jjcherry56 的 delta)比 ^frame (在原始修改后的 gud.el,它根本不起作用,并且该文件覆盖了其他语言调试器)。
因此,修改后的模式现在采用从行首到帧的任何内容,而不仅仅是零个或多个空白。更接近了,如果不是,其实"there"(甚至想关于边界条件的多实例"frame"就行了,其他深度 测试:-).
jjcherry56,我怀疑某人最初的 downvote 是因为将提问者称为 "nube",并且没有具体的解释摘要(当然不是我,而且可能过分了,特别是考虑到你的改变是有价值的,但我能理解这种反应)。
gud-lldb.el 出于您陈述的原因肯定更好,您的修复现在允许我(和其他人(你也是,Joe C))继续寻求 (继续能够)在 Mac.
上使用 emacs/gud 理智地调试
PS 我已经尝试了所有使用 gdb 的方法(我羡慕所有为它工作的人),没有运气,所以这是一个节省。嘿,我其实可以在深度设置一个断点,然后 M-x lldb 停在那里,并给我缓冲区中的箭头(它会弹出)!
我用过https://opensource.apple.com/source/lldb/lldb-69/utils/emacs/gud.el and https://github.com/ptrv/emacs.d/blob/master/site-lisp/gud-lldb.el ,以及 LLVM 3.9.1 中的 emacs 24.3 和 lldb。它可以在断点处停止,并在单独的 emacs window 中将光标显示在正确的源文件处。但是 lldb 中的 'up'/'down' 命令仅在 lldb emacs window 中显示新的源代码。没有显示新源代码的新 emacs window。
's'/'fin' 可以在不同的 windows.
中显示正确的代码这是预期的吗?
我在 emacs 25.3.1 中使用 https://github.com/ptrv/emacs.d/blob/master/site-lisp/gud-lldb.el 运气更好。它还具有不尝试修补 gud.el 的优点。我是一个更独立的解决方案。上下移动堆栈帧时也无法移动光标,但通过此更改它可以工作:
*** gud-lldb.el.orig 2017-12-11 17:22:08.000000000 -0700
--- gud-lldb.el 2017-11-18 11:52:55.000000000 -0700
***************
*** 64,73 ****
;; * thread #1: tid = 0x2e03, 0x0000000100000de8 a.out`c + 7 at main.c:39, stop reason = breakpoint 1.1, queue = com.apple.main-thread
(string-match " at \([^:\n]*\):\([0-9]*\), stop reason = .*\n"
gud-marker-acc start)
! ;; (lldb) frame select -r 1
! ;; frame #1: 0x0000000100000e09 a.out`main + 25 at main.c:44
! (string-match "^[ ]*frame.* at \([^:\n]*\):\([0-9]*\)\n"
! gud-marker-acc start))
;(message "gud-marker-acc matches our pattern....")
(setq gud-last-frame
(cons (match-string 1 gud-marker-acc)
--- 70,79 ----
;; * thread #1: tid = 0x2e03, 0x0000000100000de8 a.out`c + 7 at main.c:39, stop reason = breakpoint 1.1, queue = com.apple.main-thread
(string-match " at \([^:\n]*\):\([0-9]*\), stop reason = .*\n"
gud-marker-acc start)
! ;; cherry
! ;; (lldb) frame #1: 0x000000010013e29a sta`sta::PathEnumFaninVisitor::visitFromToPath(sta::Pin const*, sta::Vertex*, sta::TransRiseFall const*, sta::Tag*, sta::PathVertex*, sta::Edge*, sta::TimingArc*, float, sta::Vertex*, sta::TransRiseFall const*, sta::Tag*, float&, sta::MinMax const*, sta::PathAnalysisPt const*) + 986 at /Users/foobar/File.cc:348
! (string-match "^.*frame.* at \([^:\n]*\):\([0-9]*\)\n"
! gud-marker-acc start))
;(message "gud-marker-acc matches our pattern....")
(setq gud-last-frame
(cons (match-string 1 gud-marker-acc)
jjcherry56,您的更改有效。而且,既然你找到了,我就把之前的答案从 -1 投票给 0。
所以,我查看了那个增量,最后明确地做了一个小改动。
特别是,我改变了模式的一部分:
string-match "^[ ]*frame
至
string-match "^.*frame
成功了!
无可否认,gud-lldb.el、^[ ]*frame 中的 "before" 模式(来自 jjcherry56 的 delta)比 ^frame (在原始修改后的 gud.el,它根本不起作用,并且该文件覆盖了其他语言调试器)。
因此,修改后的模式现在采用从行首到帧的任何内容,而不仅仅是零个或多个空白。更接近了,如果不是,其实"there"(甚至想关于边界条件的多实例"frame"就行了,其他深度 测试:-).
jjcherry56,我怀疑某人最初的 downvote 是因为将提问者称为 "nube",并且没有具体的解释摘要(当然不是我,而且可能过分了,特别是考虑到你的改变是有价值的,但我能理解这种反应)。
gud-lldb.el 出于您陈述的原因肯定更好,您的修复现在允许我(和其他人(你也是,Joe C))继续寻求 (继续能够)在 Mac.
上使用 emacs/gud 理智地调试PS 我已经尝试了所有使用 gdb 的方法(我羡慕所有为它工作的人),没有运气,所以这是一个节省。嘿,我其实可以在深度设置一个断点,然后 M-x lldb 停在那里,并给我缓冲区中的箭头(它会弹出)!