Forum Replies Created
-
Posts
-
Thanks for the update. It looks like your support period has expired a while ago. Please kindly renew it here and we will be happy to help you.
This issue might be also caused by moving to VS2022 without uninstalling the previous VisualGDB version. Please try removing the previous VisualGDB version via Add/Remove programs (you may need to use the Microsoft Install/Uninstall Troubleshooter mentioned on our troubleshooting page) before installing VisualGDB 5.6.
Hi,
No problem. Please let us know the email address associated with your license key, so that we could link it to your forum profile.
Please also try collecting an installation log as shown on this page and attach it here so that we could see what is going on.
As we have explained above, using the ST drivers with a non-ST device would be directly against the ST license terms, and may result in undefined behavior. We do not advise anyone to do it and cannot provide any help with it.
No problem. We indeed didn’t run all our integration tests on the new build yet, and there was a glitch triggered by objects with exactly 2 gdb-level children. We have fixed it in this build: VisualGDB-5.6.101.4493.msi
Regarding the settings for pretty-printing, it is still a relatively niche option, and the “additional GDB commands” setting fully covers all cases where gdb doesn’t handle it out-of-the-box, so we will keep it this way for now.
Thank you for your feedback. We will continue monitoring the relative popularity of different device families and will consider directly supporting the ones becoming more popular.
Thanks for the screenshots. Indeed, the license looks properly loaded and should not be causing this. Could you please double-check whether the problem also happens for other projects, or if it’s specific to this one? Some manual edits to .vgdbsettings and .vcxproj files could cause hard-to-track internal errors.
You can also try using this build: VisualGDB-5.6.101.4492.msi. Please try enabling View->Other Windows->VisualGDB Diagnostics Console before changing the settings, and share the contents of the diagnostics console along with the new error message.
Hi,
No problem, we have updated VisualGDB to suppress the -var-info-path-expression command for virtual expressions. Please try this build: VisualGDB-5.6.101.4492.msi
Regarding the Python workaround, it looks like something very version-specific, so automating it on the VisualGDB side would likely only work for a very limited number of versions. That said, if applying it manually works, it should be the way to go.
Hi,
No problem, we have just released an updated Raspberry Pi toolchain: https://gnutoolchains.com/raspberry/
Hi,
No problem. VisualGDB was relying on the “numchild” field rather than “value” in order to determine whether an expression has children. As it is set to 0 for dynamic expressions, VisualGDB was indeed not showing any children in this case.
We have fixed it in the following build: VisualGDB-5.6.101.4491.msi
We have also added a setting under VisualGDB Project Properties -> Advanced GDB Settings -> Expression Evaluation that automatically issues the -enable-pretty-printing command.
Hi,
This looks like VisualGDB could not get fully activated on that computer. Could you please double-check the Help->About VisualGDB window? Does it show the correct activation information? If yes, does opening the About window before editing any settings solve the problem?
Hi,
We have just rechecked the sha1-internal.c file on ESP-IDF 4.3.1 and it worked just fine (it was not used by default until we manually disabled mbedtls crypto), so the issue could be specific to a particular project or a particular machine.
Either way, adding the __SYSPROGS_CODESENSE__ wrapper will not affect the build results (this macro is only set by the IntelliSense engine), so it should be safe to do even for library files. Due to the optimization used by VisualGDB to handle large file sets, hiding specific files from IntelliSense would be rather non-trivial, so unless the __SYSPROGS_CODESENSE__ workaround breaks specific functionality, we would advise using it instead.
Hi,
OK, we have updated VisualGDB to work with Android Studio 2020.3.1. Please feel free to try this build: VisualGDB-5.6.101.4490.msi
We have rechecked both lldb- and gdb-based debugging, and updated the gdbserver installation logic that works better on newer devices without the manual gdbserver launching workaround.
Regarding Ant, VisualGDB still supports it, although it may simply not work with the newer SDKs because it was never tested with them.
Our integration tests for legacy Ant-based projects use the following SDK versions:
Android SDK 20140702 Android NDK R10D Ant 1.9.4 JDK 1.8.0_5 We stopped testing the Ant-based build with the newer SDKs, as it has been officially discontinued by Google and hence will very likely not work at all, or will require non-trivial fixes.
If you do not specifically need any of the newer Android features, you can try downloading these versions manually, and the Ant-based workflow should work out-of-the-box. Otherwise, you may need to switch to Gradle, that is also fully supported on the VisualGDB side and should work the same way.
For reference, below are the tool versions we used to verify the Gradle-based workflow:
Android Studio 2020.3.1 Android SDK 30.0.2/31.0.0 Android NDK 21.4.7075529 Gradle 6.8 (bundled with Android Studio) Hi,
Unfortunately the VS log you provided does not show the command line used to launch GDB, and doesn’t show ALL commands issued to gdb (including the responses) before running the -var-list-children command.
The only way to understand why GDB responds differently to the same command in 2 different cases is to compare its launch commands and the other commands issued before the command in question.
