Forum Replies Created
-
Posts
-
Hi,
Yes, this is by design. The trial lets you evaluate all VisualGDB features and is hence equivalent to the Ultimate edition.
Hi,
If it is an external project managed by an external Makefile, the linker is likely re-invoked because the Makefile doesn’t handle dependencies properly.
You could try re-creating the project as an MSBuild-based project to let VisualGDB handle dependencies, although it might be non-trivial if the project has complex build settings.
Hi,
Thanks for reporting this. We have fixed it internally and will include it in the upcoming Preview 4.
Hi,
We would advise running a few quick experiments to understand what components could be causing this:
- Try profiling a “hello, world” program with VisualGDB.
- If it doesn’t work, try running valgrind manually (let us know if you need help with command lines).
- It the “hello, world” works, try running valgrind manually with your program.
If it looks like the problem is between valgrind and your specific project, please try simplifying it (e.g. removing some sources/libraries/optimization settings). If the problem occurs with VisualGDB, but doesn’t occur otherwise, it’s likely caused by some arguments VisualGDB is using. In this case please try comparing the command lines that work and the command lines used by VisualGDB (from View->Other->VisualGDB Diagnostics Console).
If you need further help at any step, don’t hesitate to get back to us.
Hi,
Most likely you are trying to use some of the features that are only available in the Custom edition.
You can find a detailed overview of VisualGDB features and different editions here: http://visualgdb.com/buy/
If you believe the message is shown by a mistake, please let us know the exact steps that lead to the message.
Hi,
The MSBuild projects define a GUI option for the debug information format (C/C++ -> General -> Debug Information Format), so specifying it via command line would result in 2 different settings passed via the command line. Please instead change the corresponding GUI setting. If the value you are trying to add is not shown in the dropdown list, simply enter the corresponding flag (e.g. -gdwarf-5) in the field directly.
Hi,
This might be caused by CMake itself caching some old settings. In that case doing a full rebuild should help.
If it doesn’t, please provide the exact steps to reproduce it and we should be able to fix it promptly.
Hi,
Yes, please use the “Custom Installation” button in the installer and it will ask you which versions of Visual Studio you want to support.
Hi,
Thanks for the log. It looks like you are using VisualGDB 5.3 that is not the latest available version. Please try VisualGDB 5.4 Preview 3 (or this build) and if the problem persists, submit an updated log.
H,
Yes, please reference the “Fast Semihosting” framework via VisualGDB Project Properties -> Embedded Frameworks.
Hi,
Just wanted to let you know that we did a few extra tests on our side and it looks like we were able to locate and fix the source of the problem. We will release an update to the ESP32 toolchain after the upcoming v5.4 Preview 4 release that will include the newest OpenOCD build with this issue resolved. Please expect an update within the next 3 business days.
Hi,
Sorry, unfortunately this error message is too generic to fully pinpoint the problem. If you could try clicking the “show details” button and paste the results here, we should be able to see what is going on and suggest a fix/workaround.
Hi,
Sorry, OpenOCD is maintained by Espressif, please consider asking at their forums. Our changes to their OpenOCD fork focus on usability improvements and out-of-the-box experience on Windows, but we don’t touch low-level device interaction logic as it changes very often between releases and relies on undocumented ESP32 internals.
We will run a few advanced tests on this build before releasing it officially and might be able to fix it if we reproduce it reliably and it turns out to be something trivial, or delay until Espressif fixes it, but we are not able to do any deep diagnostics beyond that.
Another option would be to try finding out the exact commit hash of the Linux build you are using, merging that commit into our OpenOCD fork and building it. If the problems you are experiencing are caused by some changes after that commit, this might help.
Hi,
Strange. The version number on our server is 1694. Perhaps something on your side has cached the old binary? Either way, please try this URL:
http://sysprogs.com/files/tmp/esp32/ESPxxDebugPackage.dll
Please double-check the package version after downloading/installing it.
Hi,
Thanks for the log file. Looks like the “gdb stub” debug method was not handling the esp-idf 3.1 changes properly.
Please try this build of the debug package: http://sysprogs.com/files/tmp/ESPxxDebugPackage.dll
