gdb does not stop at launch - likely because of exec-run and race conditions

[GitMensch]

Checking with the verbose option we can see

• gdb is started
• setup (config, pretty-printing, ...) is done
• breakpoints are set (and responded by GDB to be set as pending)
• -exec-run is executed
• gdb reports adjusted breakpoints (now active, with full address)
• gdb reports libraries loaded
• gdb reports running
• everything is over

This may be solved by executing -exec-run --start (so it will stop the execution at the start of the inferior’s main subprogram) and only after the "internal" startup is completely done (including getting messages for everything sent) then issuing a -exec-continue.
This should fix all race conditions on startup.

Ideally there would be an option "stopAtConnect" or similar, if this is set then -exec-continue won't be executed and we can actually stop at the start.

[jonahgraham]

Do you see gdb reporting thread exits and then stopped, reason exited? If so, then I think this is fixed by #234. In #234 if all the threads have exited then the terminate event will be sent to the client.

If not, this sounds like a different issue and a DAP + MI trace (run with verbose=true in launch.json) would be helpful.

[GitMensch]

While this is likely still reasonable to check this to prevent race conditions and to provide a "stopAtConnect" option, the bug I've seen was a different one... #239.

As soon as I've fixed the underlying issue (which was not visible) the run worked and I guess that with #234 at least the debugging session would have stopped.

[jonahgraham]

Is there anything left to do here? If there is, please provide a DAP + MI trace so I can see what is going on better and reopen the issue.

#234 should be merged soon.

[GitMensch]

Is there anything left to do here?

I think yes. But maybe I'm missing something: how can we stop the at the first instruction / at connect?

[jonahgraham]

Place a breakpoint on main? If you want that in the launch.json instead of by adding a breakpoint, add "initCommands": ["tbreak main"] to your launch config.

I suppose we could add another configuration option that would do --start on -exec-run as GDB will adjust what the tbreak is inserted on based on language.

[GitMensch]

Yes, and especially for the connect scenario that seems important.

[jonahgraham]

Please expand on "connect scenario"?

[GitMensch]

if you attach to something then you either want "run until anything happens, for example a breakpoint" or "directly stop" (similar to the launch scenario)

[jonahgraham]

OK, that is a different situation as in that case you want nothing to run, where as the start launch case you want stuff to run up until main (typically).

For the target attach (-target-attach) and select (-target-select) cases we don't issue a -exec-run, so we can't start. In those cases configurationDone (i.e. after breakpoints are inserted) we issue a continue. I know that some of the embedded extenders didn't like that so they suppress the continue in their adapters.

Lets keep discussing here, and I will try to make focussed bug reports as I think these use cases are all valid.

[jonahgraham]

First one of them is #250