Forum Replies Created
-
Posts
-
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.
Hi,
No problem, happy to clarify. A few years ago Google switched from distributing the Android SDKs/NDKs independently to having Android Studio automatically install them. Hence, on the VisualGDB side we support 2 workflows:
- The legacy Ant-based workflow using NDK R12 and an older SDK version that can be still downloaded separately. It is recommend for targeting legacy devices, or for building legacy projects created with the Ant tools.
- The new Gradle-based workflow. It involves installing the NDK/SDK via Android Studio and configuring VisualGDB to use them. You can then either import an Android Studio project as shown here, or create a new project using Gradle via VisualGDB Android Project Wizard. The new workflow utilizes the new Advanced CMake Project Subsystem, allowing to intuitively manage projects with large C/C++ code bases.
The location of the Gradle, and the exact syntax varies between Android Studio versions and we periodically update VisualGDB to match it. Following your support inquiry we have started rechecking it with the latest Android Studio 2020.3.1 and will post a link to the updated VisualGDB build here and in the support inquiry you created in the next couple of days.
GDB and LLDB work differently on different devices, so we advise trying both options to see what works the best with your setup.
The socket issue with gdbserver might be caused by the permissions on your device. Please see this tutorial for a detailed explanation of a workaround.
Hi,
No problem, if the verbose mode is interfering with the unordered_map visualization, you can turn it off via VisualGDB Project Properties -> Advanced GDB Settings -> Request verbose output from GDB.
If it doesn’t help, please make sure the native VS log does include the used GDB command line and the full output from gdb (including commands like -var-create –frame 0 –thread 1 – * “m”). Any differences in the watch window contents come from different output from -var-list-children and the only way to troubleshoot them is to understand what is causing this difference.
If GDB recognizes and reports the data via the MI interface, both Visual Studio and VisualGDB will show it out-of-the-box. If the data appears when using the regular VS debugger, but not with VisualGDB, most likely you are using different GDB settings.
If you could capture a GDB log from both VisualGDB and the regular VS debugger, and let us know the variable name in question, we can help you configure VisualGDB to show it the same way the VS debugger does.
We are sorry, as we have explained before, we do not have any plans for supporting it in the watch window and will not be able to change it.
As a workaround, please use the GDB session window. All other functionality provided by VisualGDB will work as expected.
Hi All,
Indeed, uninstalling Visual Studio while VisualGDB is already installed may trigger a few issues in the installer logic. Following our troubleshooting instructions usually helps resolve them very fast.
Hi,
No problem, you can use the GDB session window to send commands directly to GDB, including the ones to evaluate variables via libstdcxx.
Hi,
No problem, you can wrap the contents of the file with #ifndef __SYSPROGS_CODESENSE__. This will effectively hide the file from IntelliSense, while still building it as usual.
Hi,
This looks like an issue between the J-Link and the target and not something VisualGDB-specific. Please consider forwarding the log to Segger support to get more specific advice.
That said, if you can debug the target by running the J-Link gdb server manually, we can definitely help you configure VisualGDB to replicate the same results if you could share the J-Link gdb server command line that does work with this device.
