search

microsoft / debug-adapter-protocol

Defines a common protocol for debug adapters.
https://microsoft.github.io/debug-adapter-protocol/
Other
1.39k stars 129 forks source link

Provide stack frame change events #118

Open penagos opened 4 years ago

penagos commented 4 years ago

It seems there is currently no event (or reverse request) defined in the DAP to inform clients of a change in the currently active stack frame. Allowing for such communication between the debugger and the client listening to DAP events will make it easier to keep debugger/IDE state in sync.

For example, in implementing a C++ DAP extension I would like to support GDB up/down commands in the Debug Console to change the currently active stack frame in the IDE. Today, it seems the only support the DAP has for rendering a change in the currently active stack frame is when the client initiates a StackTraceRequest or when a user clicks on a specific frame in the IDE.

connor4312 commented 4 years ago

In js-debug we get around this by sending a "continued" event followed immediately by a "paused" which causes VS Code to re-request the stack. An explicit way to do this would be more elegant.

https://github.com/microsoft/vscode-js-debug/blob/482e8293bc085214c809ba4d100557d5afe6e2ed/src/adapter/threads.ts#L517-L518

penagos commented 4 years ago

In js-debug we get around this by sending a "continued" event followed immediately by a "paused" which causes VS Code to re-request the stack. An explicit way to do this would be more elegant.

https://github.com/microsoft/vscode-js-debug/blob/482e8293bc085214c809ba4d100557d5afe6e2ed/src/adapter/threads.ts#L517-L518

To my knowledge however there is no way to indicate in the response to the StackTraceRequest which frame you want to be highlighted. I.e. by sending a continued/paused event pair to VSCode the stack should be identical on an up/down command -- just the active frame should be different.

penagos commented 2 years ago

@weinand is this feature on any upcoming milestones?

weinand commented 2 years ago

The purpose of the debug adapter protocol is to provide the data that the client needs for displaying the debugger's UI. DAP's purpose is not to control the debugger's UI, e.g. to determine the selection or what stack frame is active. The UI is implemented by the client in a way so that the end user is always in control.

If the debug console (and the underlying evaluate DAP request) is used as an alternative means to drive the UI, then we would have to add a new concept to DAP.

Since this github issue has not sparked a lot of interest by other debug extension authors, I'm somewhat reluctant to assign it to an upcoming milestone.

tromey commented 1 year ago

While implementing DAP in gdb, the general concept of providing the user a way to send gdb CLI commands came up. This has a lot of implications, but one of them is handling up / down, as in this ticket ... one idea here would be if a StackFrame had selected?: bool, indicating the selected frame. Then the adapter could send an invalidated event for the stacks area when the view changed (though a more fine-grained event would be nicer to avoid any re-fetching).

AnthonyLeonardoGracio commented 4 months ago

@weinand DAP has already the concept of events, that can be sent by the server to warn the client about changes, why not use them? The stopped event could be extended for frame-changes, with a selectedFrameID info somewhere, no?

colin-grant-work commented 4 months ago

Under this definition of the debug adapter's purpose:

The purpose of the debug adapter protocol is to provide the data that the client needs for displaying the debugger's UI.

I believe that this feature request easily passes the test, particularly given the qualification that the data is for displaying the debugger's UI. To the extent that thread / frame selection plays a role for a given debugger, it (potentially) has a place in the DAP so defined.

The objection seems to come here:

The UI is implemented by the client in a way so that the end user is always in control.

Certainly in this case, where the goal is to reflect in the UI an action taken by the user through a different interface, the user is still in control. And I don't think that the objection carries weight in general, either. It would be a very strange debugger that changed important parameters unpredictably outside the user's control, so I don't think we need to worry too much about introducing user-hostile behavior by allowing debuggers to more accurately and completely report their state: a debugger that frequently does things a user doesn't want or can't understand won't find many users anyway. Instead, what this proposal prevents is desynchronizations that can make the graphical part of the debugger harder to use or less predictable / correct in its behavior.