Skip to content
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

Closed
tromey opened this issue Jan 12, 2024 · 3 comments · Fixed by #453
Closed

Ordering of launch, setBreakpoints, and configurationDone #452

tromey opened this issue Jan 12, 2024 · 3 comments · Fixed by #453
Assignees
Labels
clarification Protocol clarification

Comments

@tromey
Copy link

tromey commented Jan 12, 2024

The diagram on the overview page shows the client sending setBreakpoints, then configurationDone, and only at the end a launch.

My gdb adapter implemented this in the wrong way, assuming that launch would be send before configurationDone, 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 or attach operations provide any way for the IDE to tell the debugger which executable to examine. Without this information, though, error-checking of something like setBreakpoints 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 like launch, then debugger sends initialized event, and then configuration?

@connor4312
Copy link
Member

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 verified: false, then once the program is launched and the breakpoint binds, send a followup breakpoint event with its new state.

@connor4312 connor4312 added the under-discussion Issue is under discussion for relevance, priority, approach label Jan 12, 2024
@connor4312 connor4312 self-assigned this Jan 12, 2024
@AnthonyLeonardoGracio
Copy link

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 breakpoint events to know which breakpoints were found/not found) but it would be great if it could be explicitly written in the documentation, probably describing a little example in the breakpoint event's documentation, something like that.

@connor4312 connor4312 added clarification Protocol clarification and removed under-discussion Issue is under discussion for relevance, priority, approach labels Jan 18, 2024
connor4312 added a commit that referenced this issue Jan 18, 2024
@connor4312
Copy link
Member

I opened a PR with some clarification 🙂

@connor4312 connor4312 added this to the December / January 2024 milestone Jan 18, 2024
tromey added a commit to tromey/gdb that referenced this issue Jan 24, 2024
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.
saagarjha pushed a commit to saagarjha/binutils-gdb that referenced this issue Feb 12, 2024
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.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
clarification Protocol clarification
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants