Forum Replies Created
-
Posts
-
Hi,
Programming via COM port does not utilize JTAG or OpenOCD. It simply uploads the image to the built-in bootloader using esptool.py. You can achieve the same effect with VisualGDB by right-clicking on the project in Solution Explorer and selecting “Program FLASH memory”.
In order to do JTAG debugging, VisualGDB uses the OpenOCD port maintained by Espressif. If it doesn’t work with your hardware, please refer to the documentation from Espressif to get it working.
If you can confirm that OpenOCD works outside VisualGDB, but not when used by VisualGDB, please let us know the email address associated with your license, and we will gladly help you configure VisualGDB to replicate the results of running it manually.
This happens when the Clang IntelliSense process crashes and VisualGDB automatically restarts it. If it always happens after a “Reparsing C:\User_jof\CPP_LINUX\R3layPI\AudioManager.cpp” line, please feel free to attach a dump file produced after the crash, and we will investigate it.
Hi,
The regular VC++ IntelliSense is implemented by Visual Studio itself. VisualGDB provides it with the list of include directories and preprocessor macros from your projects, but it cannot control how it handles things internally. Depending on the project structure (or some project-specific parameters) it indeed may not work correctly. This was one of the reasons we developed the Clang IntelliSense as a replacement to it.
If you can point out specific cases where the Clang IntelliSense doesn’t work as expected (e.g. Go to Definition not working), we can gladly investigate it further.
In general, Go to Definition requires an up-to-date symbol cache (i.e. list of all symbols and relations between them). It usually takes a few minutes to build initially, but unless you frequently change the common headers used by all other files, accessing it should be almost instantaneous. Again, if you can provide a few examples when it’s not working this way (with the rough timing or a screen recording), we will be very happy to look further into it and help you get it working.
Hi,
Clang IntelliSense works differently from the regular VC++ IntelliSense. The regular Visual Studio’s IntelliSense parses the code using a faster, but less accurate method. This results in faster initial performance for huge projects, but produces less accurate results for complex cases.
The Clang IntelliSense always does a 100% accurate parse of the code (as if it was being compiled), and hence can extract precise information about the code structure, powering features like CodeJumps, Code Explorer, etc. Due to the complexity of the Clang codebase, it indeed sometimes crashes when it encounters incomplete code. Our IntelliSense engine is designed to seamlessly recover from these crashes without losing any data, so you can continue developing your project as usual, even if the engine has crashed. If it repeatedly crashes at exactly the same position, please feel free to attach the dump file it produced here, and we will investigate it further.
The #pragma once warning issued by Clang can be safely ignored. Alternatively, you can indeed switch to using include guards if you wish to eliminate the warning.
Hi,
No problem, we have a detailed tutorial on optimizing Clang IntelliSense performance: https://visualgdb.com/tutorials/intellisense/performance/
Hi,
We have just rechecked the package and it worked just fine. Please make sure your antivirus is not interfering with the package installation, and that your VisualGDB installation, or the package file is not corrupt.
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.
