Open GitMensch opened 1 year ago
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.
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.
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.
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?
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.
Yes, and especially for the connect scenario that seems important.
Please expand on "connect scenario"?
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)
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.
First one of them is #250
Checking with the verbose option we can see
-exec-run
is executedThis 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.