How to keep stopped threads stopped on attaching?

[cwalther]

Currently, when attaching to an inferior that already has some stopped threads, these threads are resumed by an indiscriminate continue command in the final continueIfNeeded call at the end of the configuration phase. This is a problem for us: our systems can have breakpoints even when no debugger is attached, and when a thread stops on such a breakpoint, we want to be able to attach a debugger and analyze the thread in this stopped state, and not have it continued. It’s also inconsistent: continueIfNeeded is supposed to be a counterpart to pauseIfNeeded, and pausing was not needed in this case because there was a paused thread already, so there shouldn’t be a matching continue either.

This is easy enough to fix, and I had done it locally months ago, but now that I wanted to prepare it for submission in a PR, I found that it breaks half the tests. Drat. Apparently the thing I had regarded as a deficiency may in fact have been a deliberate feature.

What breaks the tests is that both GDB with a native target and gdbserver (unlike our stub) stop all threads on attaching, but the tests expect the process to be running (and hit a breakpoint) after the configuration phase.

If the tests expect that behavior, then maybe some users expect it as well, so maybe we shouldn’t just change it? It even makes sense in a way from the point of a GDB native (local, type gdb) or gdbserver (remote, type gdbtarget) user, because the stop-on-attach behavior of those two destroys the original state of the inferior anyway, and there is no use preserving the destroyed state, rather what should be preserved is the state before it was destroyed, which was most likely “all running”.

I need it changed though, not just for the reason above, but also (and that’s why I hadn’t bothered submitting it until now), in a situation that I am currently working on, this change is not just nice to have, but things would not work at all without it. The situation is that the stub is not attached to an inferior yet at the time GDB connects to it, but I only issue a -target-attach 1 & command just before the end of the configuration phase, after receiving breakpoints. This is possible when using the extended-remote target in GDB. (I can go into details separately on why I am doing this, if anyone is interested.) In this case, there are no threads yet at the beginning of the configuration phase, so pausing is not needed, but they arrive before the end of the configuration phase and may all be running at that time. An indiscriminate continue in that case results in an error “Cannot execute this command while the selected thread is running.” from GDB that takes down the whole debug session.

Any opinions on how to handle this?

I can think of these ways:

• (may violate user expectations) Change the behavior unconditionally.
• (easy way out) Make it configurable using an option in the attach arguments.
• (perhaps harebrained) Define a way for a stub to advertise to the adapter that it is capable of preserving the stopped/running state of inferior threads on attaching and doesn’t want an indiscriminate continue command. Perhaps through a monitor command, or is there any other way for the adapter to talk directly to a stub?

CC @jreineckearm, @jonahgraham, @asimgunes

[jreineckearm]

Probably need to read through this with a fresh pair of eyes on Monday (public holiday tomorrow). But unless I missed something, you are describing something that was un-intuitive for us when we first started using the adapter.

We were used to debuggers that have configurable connection strategies: 1) connect and leave target state untouched, 2) connect and pause where we acquire control, 3) connect, reset, and catch at reset vector handler, 4) connect, reset, and run to main.

It took us a while to accept the continue behavior and build initCommands around it to at least reliably set up strategy 4). Making the unconditional continue configurable is still on our solution's backlog to expand for example to strategy 3) without setting a temp break at the reset handler. Just wasn't high priority enough yet to take action.

My preference would be the "easy way out". Simply because I expect many solutions based on the adapter have built provisions to deal with it. And changing it could require all these solutions to have to adopt. Also, I'd need to refresh my memory on how "blocking" a continue in initCommands would become when you don't hit an expected breakpoint like at main.

I would not limit the option though to attach but also have it on launch.

[cwalther]

Good to hear that our needs are aligned.

Next question, if we make it an option: How many values does that option need? For switching between the previous behavior and my desired new one, a boolean would be sufficient, but maybe more possibilities are needed, now or in the future? I have tried to describe these two, plus two more that someone may find useful, although I currently have no use for them, in a tabular form below:

The first two columns (input) define the four possibilities of whether we have breakpoints and whether we have any stopped threads (or no threads). The next two columns indicate whether we send -exec-interrupt (pause) and -exec-continue commands. The last two columns indicate what the result is and whether that matches the previous state. For some use cases, it may be desirable to have the same value in all rows in the result column, for others in the preserved column. With GDB native or gdbserver, only the bottom two rows occur because they always stop all threads.

Previous behavior:

bkpt	stopped	interrupt	continue	result	preserved
				running	•
•		•	•	running	•
	•		•	running
•	•		•	running

My desired new behavior:

bkpt	stopped	interrupt	continue	result	preserved
				running	•
•		•	•	running	•
	•			stopped	•
•	•			stopped	•

“never send continue”:

bkpt	stopped	interrupt	continue	result	preserved
				running	•
•		•		stopped
	•			stopped	•
•	•			stopped	•

“always stop”:

bkpt	stopped	interrupt	continue	result	preserved
		•		stopped
•		•		stopped
	•			stopped	•
•	•			stopped	•

Any opinions?

Maybe we need to keep the possibility in mind that at some point we may want an option to suppress the interrupt (pause) too (#441)? (I don’t care anymore because my stub now does not immediately stop threads when asked, but just pretends they are stopped.)

I would not limit the option though to attach but also have it on launch.

Thinking out loud: In the launch case, we are always in the bottom two rows of the tables (because “no threads” counts as stopped), and the questionable command is not continue but run. So if we suppress that, we need to give the user another way of sending it manually. As far as I can see, none currently exists (other than the debug console). Probably continueRequest() could be extended to recognize this situation and send run instead of continue.

[jreineckearm]

Thanks for the detailed analysis! Just to let you know I am not ignoring you. But was busy the entire week and now on holiday until the next CDT Cloud meeting. 🙁
Still very much interested in getting this change in, will hopefully get back with some feedback soon after I am back.

[cwalther]

No problem, I am busy with other stuff as well. And I will also be on vacation from 2026-05-14 to 2026-05-25 (so I will probably miss the meeting). I have started on a tentative implementation of an option, but it’s unclear whether I will have that ready before then.