Forum Replies Created
-
Posts
-
No worries. The MSP430 toolchain has a relatively low priority, so we would normally only update the gdbproxy when releasing a new major update to minimize the risk of breaking backward compatibility.
That said, if you have been successfully using the new gdbproxy with the new msp430.dll for a while, the chance of unexpected issues is very low. We have updated the toolchain package again with the latest gdbproxy.
No problem, we have updated the toolchain with the new msp430.dll. Feel free to re-download it via VisualGDB Package Manager (same revision number).
Hi,
host-mingw32.c is a part of the gcc source package. You can obtain it by running “sudo apt source gcc-<version>” on your Raspberry Pi, and then running “debian/rules build” to apply all patches. That said, it requires a few other non-trivial steps, and usually takes multiple hours and retries to get working.
You might be able to hotpatch it by locating the uses of pch_VA_max_size in the disassembly, and patching it directly. We can also rebuild the toolchain for you with a larger value of pch_VA_max_size, however we would have to charge 1/2 hours at our consulting rate for that, and we would not guarantee that it will solve the problem.
Strange. Do you mind sharing a screenshot of your Help->About VisualGDB window so that we could see what is going on?
Hi,
This likely happens because our Raspberry Pi toolchain is built for a 32-bit Windows environment. You can try working around it by building your own 64-bit cross-toolchain from the same sources (see Debian instructions for building toolchains). We will also consider shipping building our next Raspberry Pi toolchain for the 64-bit Windows platform.
Another option would be to try reducing the size of the precompiled header file by removing some of the headers from it.
Thanks, we have reproduced the issue and released an updated toolchain with the correct register definitions. You can install it via Tools->VisualGDB->Manage VisualGDB Packages.
Hi,
You should be able to resolve it via VisualGDB Project Properties -> Path Mapping. Simply try mapping the incorrect path e.g. (C:\proj\bf\C:\proj) to the correct one (C:\proj) and VisualGDB will automatically adjust the paths reported by GDB.
Sorry about that. We have double-checked everything and confirmed that the download page was listing auxiliary packages in the backward-compatible format that indeed would not install via VisualGDB Package Manager (it would work just fine for other package types). We have updated the page to link to the advanced packages that will work just fine. Please try downloading and installing CMake again using the updated link.
Hi,
No problem. We have double-checked it and confirmed the problem. The new ESP-IDF is using the composite statement format for idf_component_register() that is formatted using different rules.
We have added a setting controlling this behavior. Please try this build: VisualGDB-5.6.5.4406.msi
You can achieve the desired behavior by setting Tools->Options->VisualGDB->CMake->Max. Composite Statement Length to 0.
Hi,
Strange. Normally, the WSL projects should use a different type of path mapping and should not allow selecting the incorrect one in the first place. Please double-check that you select the WSL radio button on the target selection page of the wizard, rather than selecting a generic “Build on Linux” option and picking WSL in it. This helps ensure that the correct path mappings are set.
Hi,
No problem, we can gladly look into this. Do you mind sharing a screenshot of the entire Visual Studio window demonstrating the issue? The screenshot should also show the Solution Explorer and at least one source file (it’s important for checking for common module loading issues).
Hi,
No problem. VisualGDB comes with out-of-the-box support for FreeRTOS, RTX and Zephyr (NRFConnect SDK only). If you would like to target an RTOS that is not currently supported, you would need to fork our FreeRTOS plugin, and update it to handle the RTOS you are using.
As uC/OS III has a much smaller user base compared to FreeRTOS, we are not planning to support it out-of-the-box, unless some of our customers agrees to directly cover the associated porting costs.
Hi,
Indeed, the Clang-based IntelliSense engine used by VisualGDB does not rely on the .editorconfig files. It instead uses either the registry settings (when using the legacy formatter) or the .clang-format files when using clang-format.
Please refer to the following page for detailed documentation: https://visualgdb.com/documentation/intellisense/#formatting
Hi,
Please refer to the emails from our support on 2021-10-02 and 2021-10-03 for a detailed explanation on what to expect from VisualGDB. We handle support inquiries and forum inquiries exactly the same way, so the same rules apply in both cases.
Please also feel free to refer to our project importing documentation for a very detailed explanation. In short, if you would like the import to work 100% automatically, being able to build the project via command line is a requirement.
From the VisualGDB side, there is no difference between these cases. If you can build the project via command line outside VisualGDB, you can import it into VisualGDB as shown in the tutorial. If you cannot build it outside VisualGDB either, simply importing it into VisualGDB will not automatically fix the build issues.
