Forum Replies Created
-
Posts
-
Hi,
This looks like an issue with the Qt build scripts and not VisualGDB. Please refer to the Qt CMake documentation and/or Qt forums for further help with this.
That said, if you can successfully build the project manually (via the command line), but it does not work with VisualGDB, please try comparing the build command lines as shown here. If you can confirm that the command line used by VisualGDB is specifying something incorrectly, we should be able to fix it.
Thanks for letting us know. We do regularly test VisualGDB on multi-monitor configurations and have not managed to trigger the issue. Most likely, it is caused by a combination of a specific display driver and resolution settings. As the issue does not affect other users, we will not be able to allocate sufficient resources to do a full investigation at this point. However, we will keep a note of this and will double-check the multi-display functionality next time we redesign the VisualGDB Project Properties GUI.
If anyone else encounters a similar issue, please feel free to post here and we will try to re-prioritize this.
Thanks, this looks like a slightly different variation of the problem coming from the disassembly window. Please try this build: VisualGDB-5.5.104.3990.msi. If the problem persists, please attach the updated log and screenshots.
Also, in case anyone else is experiencing this, below is an explanation why it’s taking so long to pinpoint.
A recent update to Visual Studio changed the logic used by the Call Stack window so that it will sometimes try to re-query its contents while VisualGDB is already running another GDB command. This happens very rarely and intermittently, and almost never happens when a debugger is attached to the VS itself, so we have initially incorrectly concluded that VS was losing the frames reported by VisualGDB (in reality, it was sometimes re-querying them in an unsupported way that never happened with a debugger attached). We have initially updated VisualGDB to prevent VS from re-querying the frames by temporarily suspending background job processing in the main thread until the main GDB command would be completed, but it did not solve all the instances of the problem. The latest fix introduces caching instead. Now if Visual Studio queries the call stack in an unexpected way, VisualGDB will simply return the last known version of it. This may still not be a 100% solution in case VS submits a stack frame request in an unsupported context before submitting it in a regular context. As the problem is extremely intermittent and rare, it’s hard to predict whether it’s likely or not. If this happens, we will consider other workarounds as well.
Hi,
There is no advantage on building the code for Raspberry Pi Pico on a regular Raspberry Pi and it is not practical to build the code on the Pico itself. Hence VisualGDB will build the code directly on Windows using a cross-toolchain. You will be able to use a regular Raspberry Pi as a debug probe if you prefer this option.
Hi,
There is no special VisualGDB GUI for configuration-specific CMake properties, however you easily achieve this by wrapping the relevant parts of the CMakeLists file in conditional statements checking the CMAKE_BUILD_TYPE variable.
Hi,
Please refer to this page for a detailed overview of various Embedded CMake settings, including exceptions/RTTI.
Most likely, your toolchain does not support this language feature, or there is an error in the source file, or you need to select a different language standard.
Our best advice would be to try dumping the gcc command line used by VisualGDB as described here and verifying that the -std option gets passed to gcc.
Hi,
That would be normally in the project-level settings under the C/C++ -> Advanced tab. Please refer to this page for more details.
Hi,
We have already released an updated toolchain based on esp-2020r3 and the latest ESP-IDF 4.1 and 4.2 (esp32-gcc8.4.0.exe). You can install it via VisualGDB Package Manager or by downloading the file directly.
Hi,
This is why we always ask to post uncropped screenshots when reporting issues. It’s often impossible to tell what is going on without seeing the entire VS window.
Hi,
In the latest VisualGDB 5.5R4 multiple output windows have been merged in a single VisualGDB Output window (item #7 on the screenshot).
This was done because previously different output windows (e.g. semihosting or gdbserver output) would appear dynamically in front of other windows, depending on the actual output of the underlying program. Now the combined VisualGDB Output window is always shown during debug sessions and will always remember the state/location it had at the end of the previous session.
You can revert back to the old behavior using the Use Combined Output Window setting.
Hi,
Please try using the Signals button in the GDB Session window.
