[support]

Hi All,

Thanks @aronrubin for sharing your solution!

Editing CMakeLists.txt should indeed do the trick. If not, please check the generated .mak files for the compiler command lines (if -mfpu=neon-fp-armv8 does not appear there, the CMAKE_SYSTEM_PROCESSOR might not be matched properly).

If you would like to follow the tutorial linked above to the letter, you can use the VisualGDB Project Properties -> CMake Project Settings -> Extra CMake Configuration Variables setting to specify flags like ENABLE_NEON. E.g. simply “ENABLE_NEON=ON”.

[support]

Thanks for reporting this. Based on your description, most likely something in your codebase causes the Clang formatting engine to enter an invalid state that would prevent it from properly computing the indentations. We have added a few extra checks that will automatically reset the formatting engine in case it is not able to produce any meaningful results. Please try this build: VisualGDB-5.4.104.3073.msi

[support]

We have received the files and were able to reproduce and solve the problem. Turns out, a single-line comment (//comment)  at the end of a line declaring a function implementation inside a #pragma region block with CRLF line endings indeed prevented the subsequent #pragma region blocks and their contents from being recognized within the same parse operation.

Please note that the chance of guessing such a specific combination of factors from a generic description that the code folding stopped working is effectively zero and that is exactly the reason why we always ask for specific repro steps. Having a repro file and a description where to look, it took us less than 5 minutes to pinpoint the root cause. Without it, no reasonable amount of trying different combinations would trigger this issue on our side.

Please try this build, it fully resolves the problem: VisualGDB-5.4.104.3071.msi

[support]

According to our records, your trial period has expired. In order to keep receiving technical support, please consider purchasing a license.

[support]

The easiest way to do that would be to simply add the file (or the related sources) to the project via Add->Existing Items. If you are adding source files, please ensure that the directories with the header files are listed in the VisualGDB Project Properties -> Build Settings -> Include Directories.

[support]

If the problem can be reproduced on a specific file, please send it to our support email (or post it here) along with a screenshot demonstrating the problem and the exact steps we could follow on our side to reproduce it. Once we can reproduce the problem, we should be able to fix it or suggest a workaround.

[support]

Sorry, it looks like you are still using the pre-built Python executable instead of the one you built (that should be installed to /usr/local/bin) and it still fails to evaluate the ‘f’ variable that contains the frame info:

gdb --interpreter mi --args "python" "/tmp/com_sysprogs_PythonDebugWrapper.py" "/tmp/com_sysprogs_PythonBreakpointModule.so" /tmp/VisualGDB/c/Local/PRO/DT777/Tests/MSML_PyExt/../Scripts/Test_ApiGeneral.py

Below is the relevant snippet from the log:

-var-create --frame 13 --thread 1 - * "(void *)f"
^done,name="var5",numchild="0",value="0x0",type="void *",thread-id="1",has_more="0"
-data-evaluate-expression --frame 13 --thread 1 "\(void\ \*\)\(\(PyFrameObject\ \*\)0x0\)->f_localsplus\[0]"
^error,msg="Cannot access memory at address 0x178"

Please double-check that you have selected the newly built Python executable in the wizard (see step 11 in the tutorial). If it still doesn’t work, please try using the regular debugging techniques to ensure that the ‘f’ variable is accessible (declaring it volatile should normally work). Without being able to evaluate the frame context, VisualGDB will not be able to decode the state of the Python interpreter.

[support]

Good to know it works. The keywords are indeed standard, however Clang itself has a fairly complex logic for suggesting different keywords based on context, that changes from version to version. And since it is maintained by the Clang team, we want to avoid making major changes to it, hence we added a very thin layer on top that unconditionally adds the keywords specified in the settings in case Clang does not suggest them yet (we do check for duplicates, so no worries about that).

[support]

This looks correct. Based on your screenshot, there are no non-static fields or methods in the class, so code completion has nothing to show.

[support]

No problem. BTW, the “bin” prefix should normally be discarded automatically. Feel free to share your CodeModel.json file and we will update VisualGDB to compute the target ID fully automatically.

[support]

Hi,

No problem, we will clarify. This update simply adds a list of pre-defined keywords like static_cast to the suggestion lists shown by VisualGDB. Pressing ctrl-space inside static_cast<> will still show preprocessor macros, typedefs, classes and many other object types. You can limit the display to a specific type using the filter buttons at the bottom of the suggestion list.

[support]

No problem, we have fixed it in this build: VisualGDB-5.4.104.3059.msi

[support]

Hi,

Please try setting the PYTHONPATH variable to point to the directory on the board where the Python scripts are uploaded. You can set it via VisualGDB Project Properties ->Debug Settings -> Common Settings -> Debug Mode -> Additional Environment. This should ensure Python can find import all the necessary modules.

[support]

Thanks for the log file. It looks like the Python debugging is not working because the variables used by VisualGDB to analyze the Python context got optimized away.

Please follow the instructions in this tutorial to build a modified Python executable that will have the necessary variables available.

[support]

No problem, we can help you get it to work.

First of all, please ensure you have the OpenOCD package installed (you can use Tools->VisualGDB->Manage VisualGDB Packages to double-check).

Then check the %LOCALAPPDATA%\VisualGDB\EmbeddedDebugPackages\com.sysprogs.arm.openocd\edp.xml file.
The GNUTargetFilter element defines the toolchains that are considered compatible with this package:

<GNUTargetFilter>^arm-.*</GNUTargetFilter>

For Arduino projects, the GNU target is automatically derived from the name of the gcc executable reported by the Arduino build logic. E.g. for arm-none-eabi-gcc.exe it would be arm-none-eabi. You can find out the GCC path by checking the CodeModel.json file inside the build directory of your project. Simply updating the GNUTargetFilter in edp.xml to match it and re-opening the VisualGDB Package Manager to have VisualGDB reload the package definitions should get it to work. If not, please let us know the gcc executable name reported via CodeModel.json and we will investigate this further.

 

[Author]

Posts