[vim/vim] Termdebug broken on windows (program window missing and `:Break` doesn't work) (Issue #12357)

JJCUBER

unread,

May 7, 2023, 2:52:11 PM5/7/23

to vim/vim, Subscribed

Steps to reproduce

install mingw-w64 (I'm using 13.1.0 from winlibs)
open vim (or gvim) with --clean
run :packadd termdebug
run :Termdebug a (a is an executable compiled using gcc 13.1.0 with the flag -g)

This loads fine and all gdb commands input directly into the gdb window work as expected, except:

the program window is missing
using run in the gdb window makes the executable show/pop up in a completely separate window/terminal instance
:Break does not work; a message appears in the gdb window saying, -break-insert: Garbage following <location>
trying to switch the gdb layout using layout asm does not work (this might be just be a limitation and not related to my issue?)

Expected behaviour

There should be a program window where the executable to be run should "live"
:Break should set a breakpoint at the current line of the source file
layout switching in gdb shouldn't give an error (unless this is just a limitation)

Version of Vim

9.0.0000

Environment

OS: Windows 10 (22H2)
Terminal: Command Prompt (also tried using gvim)
mingw-w64: 13.1.0
vim (x64): 9.0.0000 (from vim/vim-win32-installer)

Logs and stack traces

gdb> file a
Reading symbols from a...
----
-break-insert: Garbage following <location>
----
gdb> layout asm
Cannot enable the TUI when the interpreter is 'mi2'
----
gdb> break 6
Breakpoint 1 at 0x7ff7b76f16dd: file test.cpp, line 6.
gdb> run
Starting program: C:\\Users\\JJCUBER\\Desktop\	esting clangd\\a.exe 
[New Thread 29876.0x7ab0]
[New Thread 29876.0x5018]
[New Thread 29876.0x6b90]

Thread 1 hit Breakpoint 1, main () at test.cpp:6
6	    std::cout << \
gdb> step
7	    return 0;
gdb> step
8	}
gdb> step
0x00007ff7b76f1340 in __tmainCRTStartup ()
gdb> step
Single stepping until exit from function __tmainCRTStartup,which has no line number information.
[Thread 29876.0x5018 exited with code 0]
[Thread 29876.0x7ab0 exited with code 0]
[Thread 29876.0x6b90 exited with code 0]
[Inferior 1 (process 29876) exited normally]
gdb>

—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.

ubaldot

unread,

May 16, 2024, 6:17:48 PM5/16/24

to vim/vim, Subscribed

Program window is missing/it is run in a detached window: I may be wrong, but I think this is normal if you run in "prompt" mode. The problem is that Windows does not have a pty and for this reason termdebug offers a prompt mode (check: does your prompt looks like gdb> or (gdb)? If it is the former, then you are running in prompt mode). You could run termdebug in 'terminal' mode - in that case you should have the debugged program window embedded in Vim - but you have to verify that you have winpty or the new conpty (which, be careful, it is known to not work well).
If you want to see the Asm, just run :Asm. It should open a window with the disassembled code. Check :h Termdebug.
Regarding the breakpoints it is strange because it seems to work on my computer. On a simple example, and by using :Break I have the following

Reading symbols from build\\factorial.exe...
gdb> r
Starting program: C:\\Users\\yt75534\\vimfiles\\experiments\\build\\factorial.exe 
[New Thread 21116.0x5e90]

Thread 1 hit Breakpoint 1, main () at source/factorial_test.c:19
19	    return 0;
gdb> 
gdb> c
Continuing.
[Thread 21116.0x5e90 exited with code 0]
[Inferior 1 (process 21116) exited normally]
gdb>

—
Reply to this email directly, view it on GitHub.

You are receiving this because you are subscribed to this thread.

zeertzjq

unread,

Jul 9, 2024, 7:09:18 PM7/9/24

to vim/vim, Subscribed

It seems that OP has a space in the path ("testing clangd"), and that seems to cause the error with :Break. It happens on non-Windows as well.

—
Reply to this email directly, view it on GitHub.

You are receiving this because you are subscribed to this thread.

JJCUBER

unread,

Jul 9, 2024, 7:30:22 PM7/9/24

to vim/vim, Subscribed

It seems that OP has a space in the path ("testing clangd"), and that seems to cause the error with :Break. It happens on non-Windows as well.

so would it be related to NationalSecurityAgency/ghidra#5203 ?

—
Reply to this email directly, view it on GitHub.

You are receiving this because you are subscribed to this thread.

ubaldot

unread,

Jul 10, 2024, 1:58:28 AM7/10/24

to vim/vim, Subscribed

@JJCUBER it could be. Could you please try with a filename without spaces or to use double quotes as suggested in the link you provided?

—
Reply to this email directly, view it on GitHub.

You are receiving this because you are subscribed to this thread.

zeertzjq

unread,

Jul 10, 2024, 2:03:28 AM7/10/24

to vim/vim, Subscribed

I think double quotes are needed in termdebug.vim at places where fnamescape() is used. However, I'm not sure if this will change how the filename has to be escaped.

—
Reply to this email directly, view it on GitHub.

You are receiving this because you are subscribed to this thread.

Christian Brabandt

unread,

Jul 10, 2024, 4:48:35 AM7/10/24

to vim/vim, Subscribed

Starting program: C:\Users\JJCUBER\Desktop\ esting clangd\a.exe

There also seems to be an issue with the parsing of the filenames which was fixed at commit c9a4a8a related issues: #12565, #12560 and #12550 (patch v9.0.1663)

I would also strongly recommend to re-check with an uptodate termdebug plugin, since it has undergone quite a bit of work since v9.0

—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.

JJCUBER

unread,

Jul 10, 2024, 5:38:05 AM7/10/24

to vim/vim, Subscribed

@JJCUBER it could be. Could you please try with a filename without spaces or to use double quotes as suggested in the link you provided?

If I'm not mistaken, wrapping it in quotes would be something internally performed by vim (which seems to have been discussed by others above). I'll try it on a path without a space sometime today (assuming I still have the same version from a year ago installed), then I'll try upgrading when I get the chance.

—
Reply to this email directly, view it on GitHub.

You are receiving this because you are subscribed to this thread.

zeertzjq

unread,

Jul 10, 2024, 7:43:21 AM7/10/24

to vim/vim, Subscribed

It is reproducible in Vim 9.1.532 on Linux as well:

mkdir 'foo bar'
cd 'foo bar'
echo 'int main() { return 0; }' > foo.c
vim --clean foo.c
:packadd termdebug
:Termdebug
<C-W>b
:Break

[termdebug] -break-insert: Garbage following <location>

—
Reply to this email directly, view it on GitHub.

You are receiving this because you are subscribed to this thread.

Christian Brabandt

unread,

Jul 10, 2024, 8:52:45 AM7/10/24

to vim/vim, Subscribed

This seems to fix it for the :Break command, haven't had time to check other locations that may need to parse a filename.

diff --git a/runtime/pack/dist/opt/termdebug/plugin/termdebug.vim b/runtime/pack/dist/opt/termdebug/plugin/termdebug.vim
index d00cdded2..5873a7b91 100644
--- a/runtime/pack/dist/opt/termdebug/plugin/termdebug.vim
+++ b/runtime/pack/dist/opt/termdebug/plugin/termdebug.vim
@@ -1309,7 +1309,7 @@ def SetBreakpoint(at: string, tbreak=false)
   endif

   # Use the fname:lnum format, older gdb can't handle --source.
-  var AT = empty(at) ? $"{fnameescape(expand('%:p'))}:{line('.')}" : at
+  var AT = empty(at) ? $"\"{expand('%:p')}:{line('.')}\"" : at
   var cmd = ''
   if tbreak
     cmd = $'-break-insert -t {AT}'

—
Reply to this email directly, view it on GitHub.

You are receiving this because you are subscribed to this thread.

Shane-XB-Qian

unread,

Jul 10, 2024, 11:02:26 AM7/10/24

to vim/vim, Subscribed

> This seems to fix it for the `:Break` command, haven't had time to check other locations that may need to parse a filename.
>
> ```diff
> diff --git a/runtime/pack/dist/opt/termdebug/plugin/termdebug.vim b/runtime/pack/dist/opt/termdebug/plugin/termdebug.vim
> index d00cdded2..5873a7b91 100644
> --- a/runtime/pack/dist/opt/termdebug/plugin/termdebug.vim
> +++ b/runtime/pack/dist/opt/termdebug/plugin/termdebug.vim
> @@ -1309,7 +1309,7 @@ def SetBreakpoint(at: string, tbreak=false)
> endif
>
> # Use the fname:lnum format, older gdb can't handle --source.
> - var AT = empty(at) ? $"{fnameescape(expand('%:p'))}:{line('.')}" : at
> + var AT = empty(at) ? $"\"{expand('%:p')}:{line('.')}\"" : at
> var cmd = ''
> if tbreak
> cmd = $'-break-insert -t {AT}'

> ```

May better to find out why fnameescape did not work enough for it.
// this patch seems too specific,
// besides there a few some others 'fnameescape' in termdebug too.

--
shane.xb.qian

—
Reply to this email directly, view it on GitHub.

You are receiving this because you are subscribed to this thread.

Christian Brabandt

unread,

Jul 10, 2024, 11:31:44 AM7/10/24

to vim/vim, Subscribed

May better to find out why fnameescape did not work enough for it.

That was in the message to which I replied. It seems the mi interface does not like escaping the whitespace by a backslash. It didn't like to have it quoted with a single quote. Only quoting with a double quote worked in my test.

—
Reply to this email directly, view it on GitHub.

You are receiving this because you are subscribed to this thread.

Shane-XB-Qian

unread,

Jul 10, 2024, 11:46:59 AM7/10/24

to vim/vim, Subscribed

> > May better to find out why fnameescape did not work enough for it.
>
> That was in the message to which I replied. It seems the mi interface does not like escaping the whitespace by a backslash. It didn't like to have it quoted with a single quote. Only quoting with a double quote worked in my test.

oh.. then seems lots others plugins cannot run at mingw if so.

--
shane.xb.qian

—
Reply to this email directly, view it on GitHub.

You are receiving this because you are subscribed to this thread.

Christian Brabandt

unread,

Jul 10, 2024, 12:02:26 PM7/10/24

to vim/vim, Subscribed

what does it have to do with mingw?

—
Reply to this email directly, view it on GitHub.

You are receiving this because you are subscribed to this thread.

ubaldot

unread,

Jul 10, 2024, 5:20:41 PM7/10/24

to vim/vim, Subscribed

I am not sure if I follow because every time it comes with quotes, double quotes, spaces, escape sequence, etc my brain go upside down.
Anyway, if we all agree that the problem is on the mi interface side AND there is not so much we can do from our side if not patching without never really solving the problem, what if throw an error message to the user inviting him/her/they to use filenames without spaces?

—
Reply to this email directly, view it on GitHub.

You are receiving this because you are subscribed to this thread.

JJCUBER

unread,

Jul 10, 2024, 5:41:39 PM7/10/24

to vim/vim, Subscribed

I am not sure if I follow because every time it comes with quotes, double quotes, spaces, escape sequence, etc my brain go upside down. Anyway, if we all agree that the problem is on the mi interface side AND there is not so much we can do from our side if not patching without never really solving the problem, what if throw an error message to the user inviting him/her/they to use filenames without spaces?

I think that's a bit unreasonable, considering it isn't just a filename issue but a pathing issue in general. I'd reckon that there is a pretty good chance the average user would run into a case where they have a folder with a space in the name somewhere along the current path. Furthermore, depending on what folder has the space on it, it might be something which the user can't modify.

—
Reply to this email directly, view it on GitHub.

You are receiving this because you are subscribed to this thread.

errael

unread,

Jul 10, 2024, 6:02:00 PM7/10/24

to vim/vim, Subscribed

if we all agree that the problem is on the mi interface side AND there is not so much we can do from our side if not patching without never really solving the problem, what if throw an error message to the user inviting him/her/they to use filenames without spaces?

What? Gdb is a transducer, it needs to adapt to mi. It's been pointed out that adding some double quotes on the gdb side fixes it. Seem like implementing something like MiFnameescape(), or somesuch, with whatever hacks and options are needed, solves it.

—
Reply to this email directly, view it on GitHub.

You are receiving this because you are subscribed to this thread.

errael

unread,

Jul 10, 2024, 6:43:21 PM7/10/24

to vim/vim, Subscribed

-  var AT = empty(at) ? $"{fnameescape(expand('%:p'))}:{line('.')}" : at
+  var AT = empty(at) ? $"\"{expand('%:p')}:{line('.')}\"" : at

Oops, I just looked at @chrisbra's sample fix. It's more that just quoting the output of expand(), it's quoting the whole thing. That seems inline with the gdb/mi command syntax. https://sourceware.org/gdb/current/onlinedocs/gdb.html/GDB_002fMI-Input-Syntax.html#GDB_002fMI-Input-Syntax (but that's a guess)

—
Reply to this email directly, view it on GitHub.

You are receiving this because you are subscribed to this thread.

Shane-XB-Qian

unread,

Jul 11, 2024, 6:37:26 AM7/11/24

to vim/vim, Subscribed

what does it have to do with mingw?

nevermind, was thinking a mingw issue as OP, but looks linux had such err too.

—
Reply to this email directly, view it on GitHub.

You are receiving this because you are subscribed to this thread.

ubaldot

unread,

Jul 14, 2024, 6:33:36 AM7/14/24

to vim/vim, Subscribed

This seems to fix it for the :Break command, haven't had time to check other locations that may need to parse a filename.

diff --git a/runtime/pack/dist/opt/termdebug/plugin/termdebug.vim b/runtime/pack/dist/opt/termdebug/plugin/termdebug.vim
index d00cdded2..5873a7b91 100644
--- a/runtime/pack/dist/opt/termdebug/plugin/termdebug.vim
+++ b/runtime/pack/dist/opt/termdebug/plugin/termdebug.vim
@@ -1309,7 +1309,7 @@ def SetBreakpoint(at: string, tbreak=false)
   endif

   # Use the fname:lnum format, older gdb can't handle --source.

-  var AT = empty(at) ? $"{fnameescape(expand('%:p'))}:{line('.')}" : at
+  var AT = empty(at) ? $"\"{expand('%:p')}:{line('.')}\"" : at

   var cmd = ''
   if tbreak
     cmd = $'-break-insert -t {AT}'

Implemented in #15261. Thanks for the suggestion @chrisbra !

—
Reply to this email directly, view it on GitHub.

You are receiving this because you are subscribed to this thread.

Christian Brabandt

unread,

Jul 14, 2024, 11:01:09 AM7/14/24

to vim/vim, Subscribed

Closed #12357 as completed via c3837a4.

—
Reply to this email directly, view it on GitHub.

You are receiving this because you are subscribed to this thread.

Reply all

Reply to author

Forward