Forum Replies Created
-
Posts
-
Yes, there is a setting in VisualGDB Project Properties -> Embedded Debug Tweaking that allows doing that. If you cannot find it, please let us know and we will post more details on Monday.
This is actually by design. Most IDEs (including Visual Studio) require the include search paths to be specified explicitly (deriving them implicitly tends to cause very hard-to-track errors if you have multiple headers with the same name in different directories).
Adding headers to Solution Explorer will normally not affect the build at all – the only reason for adding them is to make them easily accessible via Solution Explorer.
That said, for MSBuild-based projects you can enable automatic include path computation based on header files in Solution Explorer (VS Project Properties -> General -> Header Search Paths -> Compute Include Paths Automatically), although we would not recommend using this option in production code to avoid confusing headers with the same name.
Hi,
Strange, we have tried importing the project, but could not reproduce the issue. The _FPU_PRESENT macro was successfully imported as a preprocessor macro, so it is hard to say why it would not work on your side.
If the entire project is not confidential, please consider sending it to us as well. If it is, please follow the steps below to gather the required information on your side:
- Try importing it as an MSBuild-based project (ensure you use VisualGDB 5.5 Preview 2) and build it.
- The error window will show the specific .cpp file that is triggering the error. Make sure you can locate this file in Solution Explorer.
- Locate the .rsp file corresponding to the .cpp file in the VisualGDB\Debug subfolder. It will contain the command line passed to gcc by VisualGDB.
- Run the following command line from the project’s directory: <full path to arm-none-eabi-gcc.exe> @VisualGDB\Debug\<rsp file> and confirm that the error can be reproduced.
- Send us the .vcxproj file, the .rsp file and the exact error message produced by gcc and we should be able to find the root cause and fix the importing logic accordingly.
P.S. Based on a quick look, QP looks like a great, although very niche framework. Hence it would only be relevant for a small fraction of VisualGDB users and fully integrating it with VisualGDB would have a much lower priority than many other queued features. That said, we can always do it as a custom paid feature if anyone is willing to cover the integration costs directly. Feel free to reach out to our sales to get a quote.
Hi,
It looks like a preprocessor macro got incorrectly converted into a source or an include file.
Most likely, our importer plugin is not handling some combination of settings correctly. If you could send us the original project file you are trying to import (.uvproj + .uvopt files), we should be able to investigate and fix this.
Hi,
70 KB is still orders of magnitude less than a typical Linux kernel + rootfs, so VisualKernel does not provide any special GUI for removing the debug symbols from the built modules.
That said, you can always remove the symbols from the built module by running the strip tool (you can conveniently use the custom post-build actions if you would like to automate it).
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.
