Forum Replies Created
-
Posts
-
Thanks for the description. Looks like some of the changes you made to the project are indeed preventing VisualGDB from being loaded. The latest VisualGDB 5.4 uses a 2-stage mechanism to load itself. First, it starts a very lightweight project loader that checks the opened .vcxproj files for the $(VISUALGDB_DIR) or <Platform>VisualGDB</Platform> text. If not, it assumes the project is not VisualGDB-based and skips loading the rest of VisualGDB. This eliminates any delays when loading non-VisualGDB projects (fully initializing all VisualGDB components does take a few seconds).
VisualGDB projects created via the wizard should contain one of those strings, however if you have manually removed them, indeed the 1-st stage loader will consider this project to be a non-VisualGDB one and will not load the main part of the plugin. Please double-check the .vcxproj file for the strings mentioned above. If they are not present, please try comparing the file to a newly created .vcxproj file and adjust it accordingly.
Let us know if you need further details and we will be happy to help.
Sorry, this is actually by design. The settings in VisualGDB Project Properties are shared between all CMake targets, while the command-line arguments normally make sense only for a specific targets.
Hence VisualGDB would normally expect you to specify the arguments via the VS Project Properties for each target (i.e. item with the console icon in the Solution Explorer) separately and will automatically substitute them to the $(SelectedCMakeTargetArgs) variable based on the currently selected startup target. This eliminates the need to change the arguments when debugging another target in a multi-target project.
Hi,
Sorry, this is not supported directly yet, although it is one of the top priority features scheduled for v5.5. Please expect a preview build with this feature around late Spring/early Summer.
Hi,
No problem, we can help you resolve this.
Adding a Windows configuration to a regular Win32 project is a part of our automated pre-release tests (we have also rechecked it manually now just in case), so the issue is likely caused by some specific setting in your project. If you could share either the project that triggers this, or compare with with a freshly created one and narrow down a specific setting, we should be able to release a hotfix promptly.
Thanks for the updated log files, looks like we have found the root cause:
Breakpoint update command: +fTest_AcquisitionDelay.py:199
This line should normally contain the full path to the Python file, e.g.:
Breakpoint update command: +f/tmp/VisualGDB/e/projects/temp/LinuxProject17/main.py:3
Please double-check the path mappings via VisualGDB Project Properties -> Path Mapping. The Windows directory containing the .py file should be mapped to the location on the Linux machine where the file is uploaded. As long as this holds, VisualGDB should be able to set handle the breakpoints fully automatically.
Thanks for reporting this, we have fixed the issue in the following build: VisualGDB-5.4.105.3082.msi
Hi,
This is one of the top items in the queue (we have just released an update to VisualKernel that was another large item), so our current estimate is 1-2 months.
Sorry, we were not able to reproduce the problem based on your description. If you could reproduce the problem on a newly created LEDBlink project and share it with us, we should be able to reproduce it on our side and fix it.
Hi,
Please let us know the email associated with your license so that we could check your support status and we will be happy to help you get it to work.
Hi,
Unfortunately, the GNU Make subsystem may not work with the Nordic nRF5x SDK due to the excessively long command lines. Due to the structure of the Nordic SDK and the amount of include directories, the command lines easily exceed the 8192-character command-line limit imposed by Windows. The MSBuild subsystem automatically works around this by using response files, however GNU Make does not.
If using MSBuild instead of GNU Make is an option, please consider switching to it. If not, we can provide more details on the Windows command-line length limit, so you could attempt various workarounds, but we would not guarantee that this would work as reliably as MSBuild.
It looks like your installation is corrupt. Please ensure you are using an unmodified VisualGDB installer downloaded from our site.
Sorry about that. Indeed we checked the wrong log file. Based on the latest log, it looks like VisualGDB manages to interpret the Python frames, so the breakpoint problems are caused by something else.
Please try running the following steps in order to pinpoint it:
- Enable logging in the VisualGDB Diagnostics Console
- Set one breakpoint in the .py file and another one in your C/C++ module
- Start debugging and wait for the module breakpoint to hit.
- Attach the following information:
- GDB Session log (similar to the one already attached)
- The log from the VisualGDB Diagnostics Console (it should contain details on the Python frame analysis)
- The frame list from the Call Stack window when the module breakpoint is hit (simply press Ctrl-A, Ctrl-C to copy it)
This should provide sufficient details for us to see what is going on.
Hi,
Sorry, the behavior you described indicates that some build flags are not being properly handled by the Clang engine. Although adding the standard include directory to the search path might fix the issues in some cases, in other cases it would introduce cryptic errors like “incompatible definition of size_t”, randomly missing functions from IntelliSense suggestions, and broken “find references”.
We can help you pinpoint the root cause of the issues you are encountering – it is fully covered by our support. We have also published a detailed tutorial showing how to track IntelliSense configuration issues here. If it doesn’t help, please feel free to let us know your project type and share the relevant information from the Clang IntelliSense Diagnostics Console (per tutorial) and we will help you get it to work.
