VisualGDB threading system enhancements

[swineone]

Hello,

As briefly mentioned in this post about a new FreeRTOS plugin, VisualGDB’s threads plugin system lacks a few features that might be useful to report FreeRTOS task status. They may be limitations of Visual Studio, so I’m not sure if they can be circumvented by Visual GDB.

1. FreeRTOS tasks have an associated numerical priority. Visual Studio has a “Priority” column within the threads window, but at least when debugging C# programs, the priorities are chosen from a set (“Normal”, “High”, “Highest”, etc.) rather than numerical. The threads extensibility interface does not provide a way for plugin code to supply these priorities. If Visual Studio supports numerical priorities, I request the VisualGDB developers provide an interface for a plugin to report the tasks’ priorities.
2. FreeRTOS tasks can be in many different states (Ready, Suspended, Delaying, etc.) as can be seen in this example screenshot from an IAR/Eclipse plugin for FreeRTOS. VisualGDB does not provide an interface for a plugin to report this, although this may be a Visual Studio limitation — I’m not sure extra columns can be inserted in the threads view. However, if this is possible, I’d also like to request VisualGDB developers to support this as it’ll prove very helpful for debugging FreeRTOS tasks.
3. Again, as can be seen in the screenshot linked above, it’s possible to query FreeRTOS with regards to the remaining size of the stack in a given task. Given that memory is often a constraint in microcontroller firmware development, this is a very helpful piece of information to have, in order to optimize stack size and detect stack overflows. Subject to the same Visual Studio limitations outlined in the previous item, I’d like to request VisualGDB developers to support this.
4. Due to the FreeRTOS priority inheritance mechanism, a task may have its priority temporarily increased in order to prevent priority inversion problems. Again subject to Visual Studio limitations, I’d like to request VisualGDB developers to support an extra priority column to indicate the actual priority when a task’s priority is temporarily increased.
5. When a FreeRTOS task is blocked and waiting for a resource (mutex, semaphore, etc.), it can be queried so as to indicate on which object it is waiting for. Again this is very useful, and if a column for this could be added to the threads window, I’d like to request it to the VisualGDB developers.
6. As can be seen on the same screenshot linked from item 2, a lot more information can be queried from FreeRTOS, regarding e.g. queue status and runtime statistics information. This wouldn’t fit into the threads window, and I understand it’s a lot more work than what has been requested in the above items, but at the same time these are tremendously useful pieces of information to have for debugging RTOS applications. I’d like to request VisualGDB to add these features in the future, and I promise to support them in the FreeRTOS plugin developed at my company once they are available from VisualGDB.

Thanks

[support]

Hi,

The Visual Studio API for providing thread information is quite limited, however we could probably add a context menu item there that will show an extension-provided window with detailed information about the selected thread. Would that work for you?

[swineone]

I’ve had a look around the Visual Studio extension APIs and indeed it seems like a lot of the things I proposed cannot be implemented directly. However, according to this page, at least the priorities are supplied as a string, so that takes care of proposal #1, and in my opinion proposal #4 as well by writing something such as 0/1 or 0 (1). I could also add more information under the Priority column, such as #2, #3 and #5. Of course this would mean basically hijacking the Priority column for doing other things it wasn’t meant to do, but IMO there are advantages to seeing all the information in a single screen, instead of having to go into a separate properties dialog for each thread.

Here’s a concrete suggestion that shouldn’t be too much work for you: could you modify the interface for the threads plugin, allowing the plugin to supply a string to be passed as the bstrPriority field of the THREADPROPERTIES struct within the Visual Studio API? That should provide a solution for most of the proposals I made above.

Thanks

[support]

Hi,

We’ve made the modification you suggested and it will be included in the next preview build of VisualGDB with our new IntelliSense engine. Would you like to get a test build to try it out before we release that?

Regarding the threads window, there is no public API to add further columns, or even get the currently selected threads. However, as it is WPF-based, you can use .Net reflection to hack things dynamically (e.g. add columns on-the-fly) without breaking VS functionality. This will however most likely break in subsequent VS versions and would require modifications to accommodate the changes in the internal structure of the threads window.

[Author]

Posts