Forum Replies Created
-
Posts
-
The message about mismatching kernel symbols is shown when VisualKernel tries to read the kernel version from the target memory, using the address stored in the vmlinux file. If the result doesn’t match the version stored in the vmlinux file itself, the warning is shown. If the debugging works despite ignoring the warning, most likely the kernel contains some patches that remove the version information from RAM. In that case, the warning can be safely ignored (e.g. it does trigger incorrectly for STM32MP1 devices).
The LinuxKernelDebugHelper module uses tracepoints to trace the loading/unloading of kernel modules. If the module loading tracepoints are disabled per Linux kernel configuration, LinuxKernelDebugHelper will indeed not work. This can be worked around in one of 2 ways:
- Simply disabling the LinuxKernelDebugHelper module via VisualKernel Project Properties. This will revert to gathering module information by querying the module-related structures in debugger. This is slower than LinuxKernelDebugHelper, but will not require any configuration changes.
- Enabling the module loading tracepoints via the kernel configuration and rebuilding the kernel. This will enable the missing __tracepoint_module_load() symbol, allowing LinuxKernelDebugHelper to process module load events directly on the target, reducing the debug overhead.
Sorry, the latest ARM toolchain comes directly from ARM and we do not control the logic it uses for translating time.
As a workaround, please try using a time conversion function from an external library, or try submitting a bugreport via ARM forums.
Most likely, the file contains some invisible Unicode character that confuses Clang. Please send an archive with the project to support@sysprogs.com and we will investigate it (please delete the .vs, CodeDB and VisualGDB subdirectories before archiving the project).
No problem, please find the answers to your questions below:
- It is possible to pad the .bin file with any specified pattern by editing the linker script. Please see this tutorial.
- CRC calculation is not directly supported by VisualGDB yet, however we should be able to add it relatively easily (it would require the Custom Edition though).
- You can manually set stack/heap sizes by reserving the space for it via the linker script and overriding the _sbrk() function (that controls the heap placement). For devices with VisualGDB-generated linker scripts (e.g. STM32) this is supported out-of-the-box by referencing the “Fixed-size stack/heap” framework via VisualGDB Project Properties -> Embedded Frameworks. For other devices, this can be accomplished by editing the linker script manually (see the .reserved_for_stack and .heap sections in the STM32 linker scripts and also the StackAndHeap.c file).
No worries. This feature has been on our radar for a while. We were initially planning to add it later in the v5.5 release cycle together with other smaller MSBuild-related improvements, but as it’s always better to get feedback from real-world projects, we managed to fast-track it when you mentioned it.
Let us know if you have any feedback or other feature suggestions and we will be happy to make VisualGDB better.
Hi,
This is to be expected. VisualGDB relies on various Visual Studio services for displaying the GUI, managing the settings, etc. Hence a corrupt Visual Studio installation could indeed trigger strange errors in those services, interfering with VisualGDB functionality. Repairing both Visual Studio and VisualGDB installation is indeed the recommended way of solving this.
Clang IntelliSense fully supports renaming symbols. Simply right-click on a declaration and select “Rename” to rename it.
VisualGDB also supports C#-style renaming where you can edit the declaration name in-place and use the Quick Actions menu (Ctrl-. keyboard shortcut) to rename all references.
No problem, we have added experimental support for preprocessing linker scripts in MSBuild projects to the following build: VisualGDB-5.5.2.3415.msi
You can enable linker script preprocessing via VS Project Properties -> Linker -> Linker Script. You can use other properties on the same page to define additional preprocessor macros/include directories and to control whether the default C/C++ ones get automatically inherited.
Let us know if you have any feedback on the new feature and we will be happy to make VisualGDB even better.
Thanks for finding this out. We have updated VisualGDB to create the TestMethod element as well (VisualGDB will only set the “name” attribute, as others are not relevant to the VisualGDB test logic). Please try this build: VisualGDB-5.5.2.3414.msi
If it still doesn’t work, please try manually adding other attributes present in the regular .trx file (e.g. codeBase, adapterTypeName) and let us know which combination of them fixes the problem, so that we could update VisualGDB to set them to some dummy values.
Please try updating to the latest preview build of VisualGDB: VisualGDB-5.5.2.3413.msi
The internal structure of the Teensy core has recently changed and may no longer work with the older VisualGDB versions.
Thanks for checking this. It looks like some minor structural differences between the .trx file generated by VisualGDB and the files expected by the Jenkins tools are interfering with the parsing.
Please try the following steps to diagnose it:
- Create a dummy C# unit test with the MSTest framework. Run it with MSTest.exe and obtain a .trx file.
- Update your Jenkins setup to use a fixed .trx file generated in step 1 instead of the one produced by VisualGDB.
- Check if the test results are imported correctly. If not, double-check the Jenkins setup.
- If the .trx file produced by MSTest works, but the one produced by VisualGDB doesn’t, try eliminating the differences between them. E.g. change the test names in one of the .trx files to match the other one and then try adding the elements present in another .trx file until Jenkins starts recognizing it.
Once you determine what part of the .trx file is interfering with Jenkins, please let us know and we will update VisualGDB to generate it in a way expected by the Jenkins tools.
Yes, we have published the tutorial here: https://visualgdb.com/tutorials/profiler/embedded/coverage/
Hi,
Due to privacy reasons, we do not post sensitive license-related information on the forum. Please contact our technical support for all licensing-related issues.
