"Variables" column tightly coupled to the VARIABLES view

[AdrianOltean]

Description
Memory Inspector editors allow enabling a Variables column. A nice and useful feature but its enablement is completely unintuitive and undocumented. In other words, the column is eventually populated only if the VARIABLES view is visible and its nodes are expanded. Current implementation seems to intercept debug adapter message/responses that are related to variables retrieval and only populate the Variables column when such messages are intercepted.

From my experiments, I have never been able to see anything in the Variables column when using CPPDBG debug adapter. Whereas when using Cortex Debug, the behavior is as described above.

Requests:

1. Document the dependency of the Variables column from Memory Inspector editors. Make it clear that Variables column depends on the visibility/expanded state of the nodes from VARIABLES view.
2. When Variables column is enabled, make sure the Memory Inspector initiates requests for locals/globals/statics instead of relying on other entities (e.g. VARIABLES view) to make such requests and then simply track/intercept DAP messages.

Additional information

Memory Inspector editor with VARIABLES collapsed:

Memory Inspector editor with VARIABLES nodes expanded:

[planger]

@AdrianOltean Thank you for your feedback! I see how this is confusing. As you can imagine, this capability depends on the debug adapter that is being used with the Memory Inspector.

One key feature of the Memory Inspector is its adaptability to different debug adapters, and it is intended to enable vendors to enhance the Memory Inspector for their hardware, debuggers, etc. Therefore, the Memory Inspector reads the data, such as variables, their addresses, etc. (via the MemoryProvider) from the registered AdapterCapabilities.

To register adapter capabilities, vendors can use the Memory Inspector API.

const memoryInspectorApi = vscode.extensions.getExtension('eclipse-cdt.memory-inspector');
if (!memoryInspectorApi) {
	console.error('Memory Inspector API not found');
	return;
}

const api: AdapterRegistry | undefined = await memoryInspectorApi.activate();
if (!api) {
	console.error('Memory Inspector API is not available');
	return;
}

context.subscriptions.push(
	api.registerAdapter(new MyTestTracker(), '<debug-type>')
);

In the adapter capability implementation they can provide the respective memory information for a specific debug session and also configure the display settings:

export class MyTestTracker implements AdapterCapabilities {
	async getVariables(session: vscode.DebugSession): Promise<VariableRange[]> {
		return [{
			startAddress: '0x00000000',
			endAddress: '0x00000001',
			name: 'variableName',
			type: 'variableType',
			value: 'variableValue'
		}];
	}
	async getMemoryDisplaySettings(session: vscode.DebugSession): Promise<Partial<MemoryDisplaySettingsContribution>> {
		return {
			message: 'Vendor-XY Defaults.',
			settings: {
				bytesPerMau: 2,
				mausPerGroup: 2,
				endianness: 'Big Endian',
				addressPadding: 64,
				groupsPerRow: 'Autofit',
				visibleColumns: ['variables']
			}
		};
	}
}

So as a user, if you don't install any specific extension that adapts the Memory Inspector, the CTracker (subclassing AdapterVariableTracker) will be used for the debug types configured by default, which is "gdb", "embedded-debug", and "arm-debugger" at the moment, but users can change that.

As you can see in the AdapterVariableTracker it captures the variables when the debug client requests them, which I believe is the reason for the behavior you are observing.

Other registered AdapterCapabilities that VS Code extensions may register, can do that in a different manner of course.

[AdrianOltean]

@planger Thanks for the detailed explanation. Given that we (NXP) use our own debug adapter ("mcuxpresso-debug"), we already added it by default in the list of supported/tracked debug types from Memory Inspector, along other preferences/settings pre-configured by default. But the AdapterCapabilities part you describe is really interesting. Are you saying that if we register a custom adapter through AdapterRegistry API, the Memory Inspector will no longer depend on the Variables view to request variables that would be further "intercepted" by Memory Inspector through the default tracker? In other words, Memory Inspector will ask MyTestTracker for variables, even when Variables view from VS Code is closed/hidden? This would be really nice from our perspective.

[planger]

Are you saying that if we register a custom adapter through AdapterRegistry API, the Memory Inspector will no longer depend on the Variables view to request variables that would be further "intercepted" by Memory Inspector through the default tracker? In other words, Memory Inspector will ask MyTestTracker for variables, even when Variables view from VS Code is closed/hidden?

Yes, that's right. Your mcuxpresso-debug--specific AdapterCapabilities can use other means of retrieving the variables and residents, e.g. custom DAP messages, etc. The Memory Inspector (via the MemoryProvider) will use your registered AdapterCapabilities only, if configured correctly for your debug type.

[jreineckearm]

Yes, providing a custom AdapterCapabilities implementation is one option to deal with this. But I am curious if we could make improvements available through the default implementation. So that other debug adapters can benefit from them, too. Just wished it was possible in DAP to enumerate variables without reading their values...