[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#66604: [PATCH] Gud LLDB completions
From: |
Gerd Möllmann |
Subject: |
bug#66604: [PATCH] Gud LLDB completions |
Date: |
Fri, 20 Oct 2023 19:28:39 +0200 |
User-agent: |
Gnus/5.13 (Gnus v5.13) |
Gerd Möllmann <gerd.moellmann@gmail.com> writes:
> Mattias Engdegård <mattias.engdegard@gmail.com> writes:
>
>> 20 okt. 2023 kl. 13.12 skrev Gerd Möllmann <gerd.moellmann@gmail.com>:
>>
>>> That's interesting, the -p PID seems to make the difference. Could you
>>> please confirm? No idea what to make of that, ATM.
>>
>> I get the same odd behaviour by starting lldb without arguments and then
>> issuing
>>
>> attach ‹pid›
>> b redisplay_internal
>> c
>>
>> but not when starting Emacs from inside lldb as per your recipe, so it's a
>> matter of attaching vs spawning.
>
> Indeed. How strange.
Strangeness A:
I do
M-x lldb RET emacs RET
with a
(trace-function 'gud-lldb-marker-filter)
to observe what the process filter sees. I'm doing some stuff in lldb,
then kill the process, and attach to another running Emacs to see the
difference in what arrives in Emacs between the case of not attching to
a process and attaching to one.
Here is part of the trace output:
======================================================================
1 -> (gud-lldb-marker-filter "settings show use-color \n")
1 <- gud-lldb-marker-filter: "settings show use-color \n"
======================================================================
1 -> (gud-lldb-marker-filter "use-color (boolean) = false\n(lldb) ")
1 <- gud-lldb-marker-filter: "use-color (boolean) = false\n(lldb) "
======================================================================
1 -> (gud-lldb-marker-filter "process kill\n")
1 <- gud-lldb-marker-filter: "process kill\n"
======================================================================
1 -> (gud-lldb-marker-filter "Process 95787 exited with status = 9 (0x00000009)
killed\n(lldb) ")
1 <- gud-lldb-marker-filter: "Process 95787 exited with status = 9 (0x00000009)
killed\n(lldb) "
======================================================================
1 -> (gud-lldb-marker-filter "attach 95179\n")
1 <- gud-lldb-marker-filter: "attach 95179\n"
======================================================================
1 -> (gud-lldb-marker-filter "Process 95179 stopped\n* thread #1, queue =
'com.apple.main-thread', stop reason = signal SIGSTOP\n frame #0:
0x000000018720a8b4 libsystem_kernel.dylib`mach_msg2_trap +
8\nlibsystem_kernel.dylib`mach_msg2_trap:\n-> 0x18720a8b4 <+8>: ret
\n\nlibsystem_kernel.dylib`macx_swapon:\n 0x18720a8b8 <+0>: mov x16,
#-0x30 ; =-48 \n 0x18720a8bc <+4>: svc #0x80\n
0x18720a8c0 <+8>: ret\n(lldb) ")
1 <- gud-lldb-marker-filter: "Process 95179 stopped\n* thread #1, queue =
'com.apple.main-thread', stop reason = signal SIGSTOP\n frame #0:
0x000000018720a8b4 libsystem_kernel.dylib`mach_msg2_trap +
8\nlibsystem_kernel.dylib`mach_msg2_trap:\n-> 0x18720a8b4 <+8>: ret
\n\nlibsystem_kernel.dylib`macx_swapon:\n 0x18720a8b8 <+0>: mov x16,
#-0x30 ; =-48 \n 0x18720a8bc <+4>: svc #0x80\n
0x18720a8c0 <+8>: ret\n(lldb) "
======================================================================
1 -> (gud-lldb-marker-filter "n\n")
1 <- gud-lldb-marker-filter: "n\n"
======================================================================
1 -> (gud-lldb-marker-filter "(lldb) ")
1 <- gud-lldb-marker-filter: "(lldb) "
======================================================================
1 -> (gud-lldb-marker-filter "[1G[JProcess 95179 stopped\n* thread #1, queue =
'com.apple.main-thread', stop reason = instruction step over\n frame #0:
0x000000018721cd30 libsystem_kernel.dylib`mach_msg2_internal +
80\nlibsystem_kernel.dylib`mach_msg2_internal:\n-> 0x18721cd30 <+80>: cbz
w0, 0x18721cdd0 ; <+240>\n 0x18721cd34 <+84>: tbnz w26, #0x6,
0x18721cd70 ; <+144>\n 0x18721cd38 <+88>: mov w28, #0x7
; =7 \n 0x18721cd3c <+92>: movk w28, #0x1000, lsl #16\n[1G[J(lldb) [8G")
1 <- gud-lldb-marker-filter: "[1G[JProcess 95179 stopped\n* thread #1, queue =
'com.apple.main-thread', stop reason = instruction step over\n frame #0:
0x000000018721cd30 libsystem_kernel.dylib`mach_msg2_internal +
80\nlibsystem_kernel.dylib`mach_msg2_internal:\n-> 0x18721cd30 <+80>: cbz
w0, 0x18721cdd0 ; <+240>\n 0x18721cd34 <+84>: tbnz w26, #0x6,
0x18721cd70 ; <+144>\n 0x18721cd38 <+88>: mov w28, #0x7
; =7 \n 0x18721cd3c <+92>: movk w28, #0x1000, lsl #16\n[1G[J(lldb) [8G"
======================================================================
1 -> (gud-lldb-marker-filter "\n")
1 <- gud-lldb-marker-filter: "\n"
======================================================================
1 -> (gud-lldb-marker-filter "(lldb) ")
1 <- gud-lldb-marker-filter: "(lldb) "
======================================================================
1 -> (gud-lldb-marker-filter "[1G[JProcess 95179 stopped\n* thread #1, queue =
'com.apple.main-thread', stop reason = instruction step over\n frame #0:
0x000000018721cd34 libsystem_kernel.dylib`mach_msg2_internal +
84\nlibsystem_kernel.dylib`mach_msg2_internal:\n-> 0x18721cd34 <+84>: tbnz
w26, #0x6, 0x18721cd70 ; <+144>\n 0x18721cd38 <+88>: mov w28, #0x7
; =7 \n 0x18721cd3c <+92>: movk w28, #0x1000, lsl #16\n
0x18721cd40 <+96>: cmp w0, w28\n[1G[J(lldb) [8G")
1 <- gud-lldb-marker-filter: "[1G[JProcess 95179 stopped\n* thread #1, queue =
'com.apple.main-thread', stop reason = instruction step over\n frame #0:
0x000000018721cd34 libsystem_kernel.dylib`mach_msg2_internal +
84\nlibsystem_kernel.dylib`mach_msg2_internal:\n-> 0x18721cd34 <+84>: tbnz
w26, #0x6, 0x18721cd70 ; <+144>\n 0x18721cd38 <+88>: mov w28, #0x7
; =7 \n 0x18721cd3c <+92>: movk w28, #0x1000, lsl #16\n
0x18721cd40 <+96>: cmp w0, w28\n[1G[J(lldb) [8G"
Look at these escape sequences that suddenly appear when attaching to a
process! I don't even know what "<esc>[1G" and "<esc>[8G" do. I can't
find them in the list of ANSI sequences.
Xterm has something like that
CHA Cursor Horizontal Absolute CSI Ps G Move cursor to Ps-th
column of the active row (default=1).
But that makes no sense at all...
Don't know what happens after that that with the sequences in Emacs, but
this is already so weird that I need a pause :-)
- bug#66604: [PATCH] Gud LLDB completions, (continued)
- bug#66604: [PATCH] Gud LLDB completions, Mattias Engdegård, 2023/10/19
- bug#66604: [PATCH] Gud LLDB completions, Gerd Möllmann, 2023/10/19
- bug#66604: [PATCH] Gud LLDB completions, Mattias Engdegård, 2023/10/19
- bug#66604: [PATCH] Gud LLDB completions, Gerd Möllmann, 2023/10/19
- bug#66604: [PATCH] Gud LLDB completions, Mattias Engdegård, 2023/10/19
- bug#66604: [PATCH] Gud LLDB completions, Gerd Möllmann, 2023/10/20
- bug#66604: [PATCH] Gud LLDB completions, Mattias Engdegård, 2023/10/20
- bug#66604: [PATCH] Gud LLDB completions, Gerd Möllmann, 2023/10/20
- bug#66604: [PATCH] Gud LLDB completions, Mattias Engdegård, 2023/10/20
- bug#66604: [PATCH] Gud LLDB completions, Gerd Möllmann, 2023/10/20
- bug#66604: [PATCH] Gud LLDB completions,
Gerd Möllmann <=
- bug#66604: [PATCH] Gud LLDB completions, Gerd Möllmann, 2023/10/20
- bug#66604: [PATCH] Gud LLDB completions, Gerd Möllmann, 2023/10/21
- bug#66604: [PATCH] Gud LLDB completions, Mattias Engdegård, 2023/10/21
- bug#66604: [PATCH] Gud LLDB completions, Gerd Möllmann, 2023/10/21
- bug#66604: [PATCH] Gud LLDB completions, Mattias Engdegård, 2023/10/21
- bug#66604: [PATCH] Gud LLDB completions, Gerd Möllmann, 2023/10/21
- bug#66604: [PATCH] Gud LLDB completions, Gerd Möllmann, 2023/10/23
- bug#66604: [PATCH] Gud LLDB completions, Mattias Engdegård, 2023/10/23
- bug#66604: [PATCH] Gud LLDB completions, Gerd Möllmann, 2023/10/23
- bug#66604: [PATCH] Gud LLDB completions, Mattias Engdegård, 2023/10/23