emacs gud中的lldb不会更新“ up”的源文件

Question

I used 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 , and with emacs 24.3 and lldb in LLVM 3.9.1. It can stop at breakpoint, and display the cursor at the correct source file in a separate emacs window. But 'up'/'down' command in lldb shows the new source code only in the lldb emacs window. There is no a new emacs window showing the new source code.

's'/'fin' can show the correct code in different windows.

Is this expected?

Answer 1

I had better luck with https://github.com/ptrv/emacs.d/blob/master/site-lisp/gud-lldb.el in emacs 25.3.1. It also has the advantage that it doesn't try to patch gud.el. I is a more self contained solution. It also failed to move the cursor when moving up and down the stack frames but with this change it works:

*** 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)

Answer 2

jjcherry56, your change works. And, since you found it, I upvoted the previous answer to 0, from -1.

So, I looked at that delta, and ended up making a small change explicitly.

In particular, I changed the part of the pattern:

string-match "^[ ]*frame

to

string-match "^.*frame

And it worked!

Admittedly, the "before" pattern (from jjcherry56's delta) in gud-lldb.el, ^[ ]*frame), was closer than ^frame (which was in the original modified gud.el, and which didn't work at all, and that file overwrote other language debuggers).

So, the modified pattern now takes anything from the beginning of the line to frame, rather than just zero or more blanks. Much closer, if not, in fact, "there" (not even thinking about boundary conditions of multiple instance of "frame" on the line, and other deep testing :-).

jjcherry56, I suspect that someone's original downvote was because of the reference to the asker as "nube", and the absence of a specific summary of the explanation (it was certainly not me, and it was perhaps excessive, especially considering that your change has merit, but I can understand the reaction).

The gud-lldb.el is definitely better for the reason(s) you stated, and your fix now allows me (and others (you too, Joe C)) to move forward in the quest to (continue to be able to) debug sanely using emacs/gud on the Mac.

PS I've tried everything to use gdb (I envy all those folks for whom it worked), no luck, so this is a saver. Hey, I can actually set a breakpoint at depth, and Mx lldb stops there, and gives me the arrow in the buffer (which it will pop up)!