Multiple embedded project issues

[Comet_SL9]

I’m using VisualGDB a while now. At first, it was nice, but as one digs deeper…

Environment: STM32L4 CubeMX-using embedded project (CMAKE, mixed C11/C++23, no RTOS) with J-link as a Debugger and running Visual Studio 2022 Pro (German). The most current ARM toolchain is used (13.3 rel1).

There are multiple issues with VisualGDB which are not working as inteded:

1. Code refactoring: Refactoring tools are unavailable (only “Generate NULL checks” is shown which is not of great help). Visual Studio allows many code refactoring methods in C/C++, but when the VisualGDB environment is used, all of those vanish. That’s quite unfortunate and slows down development significantly by using manual methods. Even the free-of-charge STM32CubeIDE (which I left behind for using VisualGDB) can do automated refactoring.
2. Fast Semihosting output in the “VisualGDB Output” window: Works… kinda. When using repeated printf-generated outputs (which could fill up the ring buffer which is set to 4096 bytes), the output becomes totally scrambled with extended ASCII characters and does not recover. Only a debugger restart resolves this (Detach and reattaching to running firmware does not). The ring buffer itself and the state variables in “s_FastSemihostingState” are totally fine and readable, I’ve checked this via a memory dump. There is no stack corruption.
3. Sampling profiler: It samples, but only shows raw hex addresses instead of analyzed method names in the live profiling window (and profiling report file). The .map file is generated in the output folder. If I do it by hand, I can figure the method names out, but… we’ve got a computer here to do such kind of work. When selecting “Breakdown to line numbers”, “(unknown source location)” is shown. How to get the method name resolution to work?
4. When adding new source files, the “select folder” dialog always restarts at the “This PC” level and one has to dig down until one get’s to the project directory each time (even when right-clicking on the correct directory in the project to select “add new element”). Not quite comfortable.

Remarks: The same issues plague me on all other embedded projects, some of them are Renesas RA6M5-based or STM32H7-based, too (with FreeRTOS; on a different PC, as well). Seems to be all ARM Toolchain related.

Attachments:

You must be logged in to view attached files.

[support]

Hi,

No problem, please find the detailed answers below:

1. VisualGDB offers a different set of refactoring tools from the regular VS. E.g. it has the create-from-use functionality that normally only works for C# projects, but doesn’t have the “extract function” feature. Other refactoring features are implemented via RefactorScript – an extensible scripting language for generating boilerplate code. If you are looking for a particular refactoring feature, let us know and we will advise how to find it.
2. This looks like the memory buffer in the program gets corrupt, so VisualGDB cannot make sense of what it’s getting from the target. Just overflowing the buffer should not be causing it. Please try reproducing the problem on a clean project created from scratch. If it doesn’t happen there, please try comparing it against the original one.
3. Normally, address resolution should work. Please try checking it with a clean project created from scratch. If it works there, but not on the actual project, it could be caused by inconsistent debug symbols in the project, or by a bug in the VisualGDB’s profiler. If this is the case, we can investigate it further if you could share your ELF file. We would kindly ask you to renew your support first though.
4. We have rechecked it and it worked just fine. If it doesn’t work as expected, please make sure you can reproduce the issue on a clean project created from scratch, and then share the complete repro steps as described here. You can also record a screen video showing the problem if you do not want to take multiple screenshots.

[Author]

Posts