Forum Replies Created
-
Posts
-
Hi,
Most likely, you have picked up an incorrect remote machine in the “Transfer directory” action. Please double-check all the action settings.
If this doesn’t help, please make sure you can reproduce the problem on a project created from scratch, and then share the steps we can follow to reproduce it on our side. Please make sure you include the relevant screenshots, as otherwise we won’t know what exact settings you have changed.
Good to know it works. We usually want to minimize the changes to the GCC sources when building our toolchains, because it often has unforeseen side effects (e.g. increasing the size of one buffer could prevent something else from being allocated).
The difficulty of patching would depend on how many assembler instructions would be affected by the change, and how difficult would it be to locate them. From a very brief look into the source, it looked like it would only affect a couple of instructions near public API calls, so it’s easy to find them.
Either way, feel free to share the bytes you changed in the executable, so that other users could replicate it if they run into anything similar before we release a 64-bit toolchain.
Please note that VisualGDB focuses on improving the typical development scenarios that would otherwise take a lot of our customers’ time. E.g. we provide a powerful Clang-based IntellISense engine that allows exploring large code bases, more reliable debugger integration, convenient GUI for configuring common settings, deep integration with Valgrind, CMake and numerous other tools, etc. You can find more about VisualGDB features for Linux here.
If none of these features made VisualGDB worthwhile for you in 6 months, adding support for visualizing a very specific container will not make much of a difference. So instead, we have to focus on features that would make a difference in the context of common tasks (e.g. the newly added Code Explorer is a huge help when dealing with large projects).
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.
