Feature Request: Addtional Scopes in Variable display

[john5f35]

While looking at LLDB debug extension by Vadim, I found its Variable display very powerful. It includes not only Local variables, but also static and global variables, and various registers in categories. I find this quite good. The Cortex register views and Peripherals can become part of this. What do you think, @Marus?

Below is a screenshot of using the LLDB extension, and examining the variables and registers.

[Marus]

I am planning on adding global/static variable scopes. Once I finish up the refactoring work I am currently doing (hoping that will all be finished today).

I do have a few reasons why I am not currently keen on the idea of moving the registers and (particularly) peripheral data into this view:

• With the variables view I am limited in the ways I can present the values; for example on fields that define enumerations I present both the raw value, as well as the enumeration value.
• Limited to how I can accept input for editing values; in the case of fields with enumerations I present a pick-list with the appropriate values.
• Unable to restrict editing attempts on read-only registers at the UI (they would of course fail).

(ST’s SVD files are a bit lacklustre, so you may not see the advantages of the enumerations support as they probably don'thave any; I also plan to at some point make my own enhanced versions for some of the ST parts I use regularly)

This is not to say the variables view doesn’t have advantages as well (in particular the fonts/formatting is a bit nicer than what can currently be done in the custom views).

The custom views system is still fairly new to Visual Studio Code, and while it is somewhat limited currently, I do feel that it will be improved in the future. I do plan on making feature requests (and time permitting, pull requests) to enhance the capabilities of those views so that I can get the presentation I would truly like to achieve in those views.

While I’m not saying this is a definite no forever, I will not be making this change currently.

[Marus]

The Global/Static Variables will likely take a bit longer to deal with than I originally expected.

The GDB MI doesn't have a convenient way to access a list of global/static variables (there used to be a -symbol-list-variables command - as an equivalent to info variables; this has been removed from modern versions of the GDB MI with no replacement).

This will likely result in having to use the regular info variables command and parsing the human readable output; another option will be parsing output from objdump to find the symbols, this may be easier to implement as I already have some code for parsing objdump output as I'm using it to support some basic profiling through the SWO output.

While I do still plan to implement this, I will likely delay it from right away, as it is still possible to access global variables if you need it via a watch (although certainly not as conveniently as if they were a scope in the main variables view).

[john5f35]

Hi Marus, thanks for the explanation. Yeah, I guess enumeration could be tricky on the Variable view. One way it might be able to work is to display an error message informing invalid input, and list valid values. And for read-only values just silently ignore value setting. I guess it’s a subjective thing as to which one is better. Being able to select values also sounds good, and I do hope that the customed views support in VSCode will be able to improve.

I’m surprised about the removal of global variable info command from GDB MI. It is stilll somehow in the online documentation. Which version of GDB does it affect?

[Marus]

Yeah - it's more about what I hope I will be able to do in the future - I'm going to be making feature requests (and maybe try implementation myself) for expanding the custom view capabilities. If the VS Code seems receptive to the requests I will likely leave them in separate view - as I do think it has the potential to be better than integrating it with variables (even if it isn't currently). I think giving them a solid example of what I'm trying to do with the custom views helps the case for improving their capabilities (there are already some issues about expanding the view capabilities). If they end up being completely unreceptive - then I may reconsider my position.

Regarding the global variable info command (-symbol-list-variables) it is strange - I can find references to that command in some older versions of the documentation - but it is not in current documentation. From posts I can see online it is unclear to me if a) it was previously implemented and then removed or b) it was planned but never implemented. I expect it is actually b - was planned and documented but never implemented. If it was ever implemented then I expect it must have been dumped when it went from MI1 to MI2 (MI1 was used for GDB 5.1 to 5.3).

I've been experimenting today with the approach of parsing the symbol table from the objdump output (since I already had most of the code for parsing that output already for the profiling support I am working on) - and have a working (although not thoroughly tested yet) globals scope. Still need to add some things to my parsing of the symbol table to associate static variables with their file so I can do a proper statics scope. So hopefully won't be too long to get global and static scopes.

[john5f35]

Good work! I’m looking forward to VSCode’s reply. :)

[Marus]

I've got the Static variable scope sorted out as well now; so both the global and static variable scopes will be added in the next release (along with all the cleanup of the structure to better handle the numerous GDB server option - as I ended up adding more options than I originally intended when I started it).

I expect I'll release an update tomorrow or Wednesday with those changes - have a few little bits I need to clean up still - but will be soon. Then I need to write some documentation.

With this new release is out you should make some slight adjustments to your launch.json files (although it will try to map them automatically) - as now they will all be under one type (cortex-debug) with a separate servertype parameter (stutil in your case).

[john5f35]

Cool, I'm looking forward to it. 👍

[Marus]

I've published a VSIX file on GitHub (v0.1.10-pre). If you have time you can try it out before I push it up to the marketplace.