Auto-fill certain memory display settings based on characteristics of a debug session

[planger]

Description There are a few memory display settings that may be configured automatically in the context of a specific debug session, e.g. they depend on the target architecture. Those settings may include:

• Padding memory addresses for a 32bit or 64bit architecture
• Word size
• Special floating or fixed point formats
• More?

To accurately set these parameters, several approaches could be considered. Thus, it might be necessary to introduce an extension point (VS Code extension API) enabling other extensions to contribute to the configuration, possibly by reading certain properties of a launch configuration, using custom Debug Adapter Protocol (DAP) messages, or other indicators specific to the debug session.

[planger]

@colin-grant-work @jreineckearm I've created this issue to have a common place for continuing the discussions started in https://github.com/eclipse-cdt-cloud/vscode-memory-inspector/issues/48#issuecomment-1942394325 and https://github.com/eclipse-cdt-cloud/vscode-memory-inspector/issues/48#issuecomment-1946357358. I feel there are a few settings that depend on the debug session context and we probably want only one consistent solution for all of them, which seems to deserve an own separate issue.

I think introducing an extension point enabling other extensions to contribute to the derived settings, based on whatever data source they want (DAP messages, launch configuration properties, etc.) feels most appropriate, what do you think?

[colin-grant-work]

I'm not sure that I understand the relevance of architecture to address padding. I think the approach that would make most sense to me for padding would be to check the range of addresses available in a given view and then pad (at least) the minimum to ensure uniform length in the address column. I'm not sure why more padding might be desired, but if a case were made, I wouldn't be opposed to it.

[jreineckearm]

I agree with the need to open up a contribution point. A lot could already be achieved by well-defined launch config items. But there is a mild concern that this could become unmanageable at some point on that level. So, an API sounds like the cleaner approach.

Regarding the address width padding, I'd be in favor of this change, at least as an option. It at first may appear just as a cosmetic thing. But it IMO has other advantages:

• It would help to reduce "noise" perceived by users when scrolling in lower memory regions like starting from address 0x0.
• Another side effect is that it helps the user to get visually reminded of the debugged CPU architecture. This may be very useful if debugging multiple CPUs of a heterogeneous multi-core design in parallel. Where you have a mixture of 32-bit and 64-bit CPUs and switch between memory window instances.