-
Notifications
You must be signed in to change notification settings - Fork 127
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Ordering of launch, setBreakpoints, and configurationDone #452
Comments
Your interpretation of the diagram is right. There's no out of bound signalling, nor should the client indicate add anything extra in the initialize request. Adapters can update the state of breakpoints asynchronously via the breakpoint event. What many adapters do is initially respond to the breakpoint request indicating the breakpoint is unverified with |
Hello @connor4312! I am working on the implementation of DAP on GNAT Studio's side, working with @tromey. Your proposal looks ok to me (i.e: fully rely on |
I opened a PR with some clarification 🙂 |
Co-workers at AdaCore pointed out that gdb incorrectly implements the DAP launch and configurationDone requests. It's somewhat strange to me, but the spec does in fact say that configuration requests should occur before the executable is known to gdb. This was clarified in this bug report against the spec: microsoft/debug-adapter-protocol#452 Fixing 'launch' to start the inferior was straightforward, but this then required some changes to how breakpoints are handled. In particular, now gdb will emit the "pending" reason on a breakpoint, and will suppress breakpoint events during breakpoint setting.
Co-workers at AdaCore pointed out that gdb incorrectly implements the DAP launch and configurationDone requests. It's somewhat strange to me, but the spec does in fact say that configuration requests should occur before the executable is known to gdb. This was clarified in this bug report against the spec: microsoft/debug-adapter-protocol#452 Fixing 'launch' to start the inferior was straightforward, but this then required some changes to how breakpoints are handled. In particular, now gdb will emit the "pending" reason on a breakpoint, and will suppress breakpoint events during breakpoint setting.
The diagram on the overview page shows the client sending
setBreakpoints
, thenconfigurationDone
, and only at the end alaunch
.My gdb adapter implemented this in the wrong way, assuming that
launch
would be send beforeconfigurationDone
, and so the latter is what actually causes the inferior to run. (I overlooked the or misread the diagram...)However, looking at this now, I don't see how this is intended to work. As far as I can tell, only the
launch
orattach
operations provide any way for the IDE to tell the debugger which executable to examine. Without this information, though, error-checking of something likesetBreakpoints
is basically impossible.The section "Configuring breakpoint and exception behavior" seems to try to address this issue, but I find it a bit vague.
I would appreciate a clarification here. Is it expected that the IDE communicate the executable via some out-of-band approach, like a command-line argument? Or is it appropriate to add an extension to the
initialize
request to indicate the executable to use? Or is the sequence supposed to be something likelaunch
, then debugger sendsinitialized
event, and then configuration?The text was updated successfully, but these errors were encountered: