vscode.debug API should provide the current thread/stack frame ids

[gregg-miskelly]

Currently the vscode.debug API provides a way to send custom events to debug adapters. But it is missing one fairly important thing - there is no way to know what the current thread id / frame id is. So a debug adapter could maybe guess. But it feels like there should really be a way to query this.

[geajack]

Hi @hediet, I noticed you self-assigned this recently. I was wondering, is there any kind of plan as to what an eventual API on this might look like? I also wanted to check that this feature request is the same one discussed on a different repo here. Is the idea here to allow access to the ID of the "current" stack frame in the sense of the one that the user has selected in the VS Code debugger view in the sidebar?

[hediet]

It is unclear if this ever gets implemented, but I have a personal interest in it, thus I assigned it to myself to keep track of it.

[elazarcoh]

@weinand Will you accept a PR for this?
I have the code here.
I tried to keep it smallest and coherent with existing code as possible.

[weinand]

@elazarcoh In principle we are willing to accept a PR. But since this is extension API it has to go through our extension API review process.
The first thing we need is an API proposal.

[elazarcoh]

is it something I can start? or it is something that is done only internally

[weinand]

@elazarcoh you can start just here.
Please study some existing API items with the "api-proposal" label to learn how API proposals look like.

[PaDebug]

Hello,
I also need the feature (get the current user selected frame id) in order to update the windows of the debugger extension (especially for multi-core devices). Does this feature make progress? Is there any workaround to get the frame id?

[elazarcoh]

@PaDebug if you'd like to help, you can write the API proposal. That would be the first step.

[PaDebug]

@elazarcoh What do I need to do to write the API proposal?

I would propose extending the debug namespace by an event which fires when the user selected a different stack frame in the call stack window. For example:

export namespace debug {

/**
 * An event which fires when the user selected a different stack frame in the call stack window.
 */
export const onDidChangeSelectedStackFrame: Event<StackFrame>;

}

The interface StackFrame consists of two properties: frameId and associated threadId. This would provide enough information to update the thread and stack frame in the Debug Adapter via custom request.

export interface StackFrame {

/**
 * Id of the associated thread (DAP id).
 */
readonly threadId: number;

/**
 * Id of the stack frame (DAP id).
 */
readonly frameId: number;

}

What do you think about this?

[elazarcoh]

@elazarcoh What do I need to do to write the API proposal?

I would propose extending the debug namespace by an event which fires when the user selected a different stack frame in the call stack window. For example:

export namespace debug {

/**
 * An event which fires when the user selected a different stack frame in the call stack window.
 */
export const onDidChangeSelectedStackFrame: Event<StackFrame>;

}

The interface StackFrame consists of two properties: frameId and associated threadId. This would provide enough information to update the thread and stack frame in the Debug Adapter via custom request.

export interface StackFrame {

/**
 * Id of the associated thread (DAP id).
 */
readonly threadId: number;

/**
 * Id of the stack frame (DAP id).
 */
readonly frameId: number;

}

What do you think about this?

@weinand will this do?

[haneefdm]

If this is implemented, it needs to be specific to a session. As in threadId/frameId are not enough. We have to deal with multiple concurrent debug sessions. Needs DebugSession object or at least the sessionId.

Doesn't frameId encapsulate/include threadId from a DA's perspective?

[gregg-miskelly]

Doesn't frameId encapsulate/include threadId from a DA's perspective?

Yes, but I think you want to expose both so that a VS Code extension could call any DAP API which either took a thread id or a frame id.

[roblourens]

@gregg-miskelly @hediet could you tell me what the use case is? And does "current" mean "selected in the UI"?

[gregg-miskelly]

Yes, "current" means the one selected in the UI.

I originally ran into this when I wanted to implement Set Next Statement in the C# extension before the VS Code UI added support for it. It has also come up when potentially wanting to support a disassembly window (though again, this was solved by building the feature in VS Code instead). My team doesn't have a current need for this, though I still think this is a good idea as this makes the extension API very limited in terms of building any kind of debugger feature. Without this feature, it isn't possible for an extension to make valid DAP requests for lots of feature areas, especially anything involving looking at variables/expression evaluation.

[geajack]

For another use case, I ran into this when trying to develop a debugging extension for Python. One of the features was that you could type in a variable name, or more generally an expression, and you would get back a certain visualization of the value of that expression. In order to do this, the extension sends the expression over the DAP to have Python evaluate it and send the value back. However, the variable, or any variables in the expression have to actually be in scope for this to work.

If the user clicks back to a different stack frame in the UI, they can now view the values of variables in the built-in VSCode debugging panel. Since my extension also allows you to, in a sense, view the values of variables, the user expects to be be able to use it for any variables that they can see in the debugging panel. So I need to know when they switch stack frames to give them that experience. Right now my extension basically maintains a parallel list of stack frames in the UI, so if the user wants to climb back up the call stack and use my extension, they have to click the stack frame in both VSCode's built-in UI and in my extension's UI.

[hediet]

My use case is my debug visualizer extension. When the user selects a different stack frame than the top one, the watch windows and the visualizer window disagree.

[mblout]

I also have a use-case for having additional views participate in the debugging; being able to show a custom "registers" view that tracks with selection, for example. We also have some breakpoint functionality that changes if we're in an active session, and would leverage the active thread to 'scope' which threads for which it is active.
So, I'd want to both interrogate the current/selected thread/stack frame (in session context) and to listen for changes

[mblout]

Wanted to ask if there is anything I can do to make the discussions about promoting this proposed API easier?
Would a runnable demo help, like a vscode-mock-debug pull request?
Animated GIF or other form of doc/example? Thanks again!

[connor4312]

This API has been finalized and will in tomorrow's Insiders and the next stable release. Please refer to https://github.com/microsoft/vscode/pull/212190/files#diff-0a75aed19c118603eb96332bc0b9c2d7867f4182346d16d18b7fc31b6ceeb321 for the final API.