Support non-stop mode for gdb debugger

[AnatoliShein]

From GDB documentation:

GDB supports an optional mode of operation in which you can examine stopped program threads in the debugger while other threads continue to execute freely. This minimizes intrusion when debugging live systems, such as programs where some threads have real-time constraints or must continue to respond to external events. This is referred to as non-stop mode.

This is a must have feature if you are working on complex multi-threaded applications. Some visual debuggers that use gdb (e.g. eclipse) already have support for non-stop mode, and it would be awesome to get it in vscode as well.

[konradsa]

I second this request, very important feature to have IMHO.

[Trass3r]

The question is what is needed to support that. You can already enable it manually by adding set non-stop on to the startup commands. I guess breakpoints would need to be attachable to specific threads (DAP change) and some more controls to run and stop single threads: https://wiki.eclipse.org/images/3/36/ReverseDebuggingEclipseCon2009.pdf

Edit: indeed, like for each thread there are execution buttons of which only the stepping ones work as expected. Continue resumes the current thread instead of the clicked one. Otoh it's debatable if these buttons shouldn't do their job without changing the current thread, via https://sourceware.org/gdb/current/onlinedocs/gdb/Background-Execution.html

[KUGA2]

This feature is very valuable when debugging IPC mechanisms like semaphores. I would argue it is a must have!

[Gnomey123]

The new Rasberry Pi Pico also needs this to run; we really need to have this

[Gnomey123]

ref: https://forums.raspberrypi.com/viewtopic.php?f=144&t=320558#p1919327

[exploman]

I have been following this issue for two years. I use gdb non-stop mode in multithreading and occasionally it can cause the program to terminate.

[rohanrhu]

FYI you can use my debugger if you need a proper GDB shell and all features without this kind of issues.

https://github.com/rohanrhu/gdb-frontend

I always use VSCode on every platform for everything but using GDBFrontend for debugging. It is useful when you use it in your Docker setup, especially for test releases of servers since you are easily able to access your debugger on web interface and remotely debug without any feature restriction.

[KUGA2]

The question is what is needed to support that. You can already enable it manually by adding set non-stop on to the startup commands. I guess breakpoints would need to be attachable to specific threads (DAP change) and some more controls to run and stop single threads: https://wiki.eclipse.org/images/3/36/ReverseDebuggingEclipseCon2009.pdf

Edit: indeed, like for each thread there are execution buttons of which only the stepping ones work as expected. Continue resumes the current thread instead of the clicked one. Otoh it's debatable if these buttons shouldn't do their job without changing the current thread, via https://sourceware.org/gdb/current/onlinedocs/gdb/Background-Execution.html

I fell across this problem again today. So I will elaborate this further.

First: manually by adding set non-stop on to the startup commands means to add this to launch.json:

        "setupCommands": [
            {
                "text": "set pagination off",
                "ignoreFailures": true,
            },
            {
                "text": "set non-stop on",
                "ignoreFailures": true,
            }
        ],

(I read somewhere that pagination should also be turned of, but I do not know what this really does)

Then verify start your program with debugger attached ( and verify your setting in debug console (run -exec show non-stop):

When running in non-stop mode, the thread list and stack is very unreliable (They are paused on the gui, running on the right)

So what would I wish for:

1. Setting non-stop mode via a specific launch.json element
2. Gui should work correctly.
   • Correct task state (running/break)
   • Run and step buttons in sidebar should work and only work on the selected thread. The overall/regular buttons should display the currently selected thread by name and id.
   • The call stack should be correct

[borjamunozf]

Any info or update for this?

The question is what is needed to support that. You can already enable it manually by adding set non-stop on to the startup commands. I guess breakpoints would need to be attachable to specific threads (DAP change) and some more controls to run and stop single threads: https://wiki.eclipse.org/images/3/36/ReverseDebuggingEclipseCon2009.pdf Edit: indeed, like for each thread there are execution buttons of which only the stepping ones work as expected. Continue resumes the current thread instead of the clicked one. Otoh it's debatable if these buttons shouldn't do their job without changing the current thread, via https://sourceware.org/gdb/current/onlinedocs/gdb/Background-Execution.html

I fell across this problem again today. So I will elaborate this further.

First: manually by adding set non-stop on to the startup commands means to add this to launch.json:

        "setupCommands": [
            {
                "text": "set pagination off",
                "ignoreFailures": true,
            },
            {
                "text": "set non-stop on",
                "ignoreFailures": true,
            }
        ],

(I read somewhere that pagination should also be turned of, but I do not know what this really does)

Then verify start your program with debugger attached ( and verify your setting in debug console (run -exec show non-stop):

When running in non-stop mode, the thread list and stack is very unreliable (They are paused on the gui, running on the right)

So what would I wish for:

1. Setting non-stop mode via a specific launch.json element

2. Gui should work correctly.

* Correct task state (running/break)

* Run and step buttons in sidebar should work and only work on the selected thread. The overall/regular buttons should display the currently selected thread by name and id.

* The call stack should be correct

[KUGA2]

Any info or update for this?

From my side? No. I just thought this thread needs more pictures and examples of why we cannot use non-stop mode in VSCode right now. Posts here might suggest otherwise.

Maybe a dev will implement this eventually.

[xiongqr]

Confirmed. GDB non-stop mode does not work in Vscode. I will use the above screen shot to point out 2 issues.
1) Thread statuses are wrong. After setting a thread-specific breakpoint(lcore-worker-8 thread here), only that thread should be in "PAUSED" status, all other threads should be in running status. 2) does not work correctly. If it is clicked, the thread specific break point will not be hit.

[KUGA2]

Every now and then I am in heavy need for this feature to find race conditions. Now is the time. I then have to resort to gdb itself. It is a pitty.

[pereyra-m]

It'd be useful!