Forum Replies Created
-
Posts
-
Unfortunately, the description you provided does not contain sufficient details for us to reproduce the issue. Please consider describing the issue per our problem reporting guidelines so that we could try reproducing it on our side.
Unfortunately, the description you provided does not contain sufficient details for us to reproduce the issue. Please consider describing the issue per our problem reporting guidelines so that we could try reproducing it on our side.
Looks like you are referring to the this thread.
We have mentioned that the oldest version of FreeBSD tested with SysprogsSync was 9.3. Once you provided more details, we pointed out that the error was caused by a 32-bit build of FreeBSD, and that using a 64-bit build, or patching SysprogsSync as we suggested, would solve the problem.
If you do not have any specific version constraints, please try using a 64-bit build of the latest FreeBSD. Although some minor functionality may not work as expected, most of the functionality should work.
It also looks like your forum account is using a different email address that is not linked to your license key. Please let us know the email address associated with your key via the support form, or update the forum profile accordingly, so that we could link it to your support profile.
Edit: the latest error looks like the latest gdb might not be compatible with the FreeBSD version you are using. Sorry, unfortunately this is outside of VisualGDB’s control. Please try installing the latest 64-bit FreeBSD as suggested above.
Sorry, VisualGDB does not support GDB 6.1, as it is more than 15 years old and is missing many critical functionality. If you absolutely have to use this version, we could add limited support for it as a custom paid feature. Please contact our sales to get a quote.
Hi,
Looks like your gdb version does not support some of the gdb/mi commands used by VisualGDB. Normally, updating to gdb 7.0 or later (although we recommend the latest 8.3.1 release) should solve the problem.
Hi,
Sorry, this is by design. 82 is the correct decimal value for 0x52. You can switch between the decimal and hexadecimal view by right-clicking in the Watch window and selecting “Hexadecimal View”.
Thanks for the detailed logs. Turned out, a recent optimization on our side broke display of some typedef’ed variables.
We have fixed the issue in the following build: VisualGDB-5.5.2.3385.msi
Good to know it works. We have also double-checked the download file extension and it appears correct. If you encounter the issue again, please let us know the repro steps and we will investigate.
Hi,
This looks like VisualGDB incorrectly reformats the value obtained from gdb. If you could share a full gdb log and a log from View->Other Windows->VisualGDB Diagnostics Console, we should be able to find the root cause and release a hotfix promptly.
Hi,
Looks like you don’t have sh.exe in your PATH variable. Please try adding the directory containing it (would normally be bundled with your Git installation) to PATH, or edit the run-sh.bat file inside the OpenOCD repository to specify the path manually.
We have also updated our OpenOCD repository to show a more meaningful message when sh.exe is missing.
Hi,
Please follow this tutorial to diagnose common library-related problems.
Hi,
Currently we are still researching the ways to reduce the RAM use by the profiling counters. We should be able to get an ETA for this feature around the middle of the next week.
Thanks @Jensa for confirming that it works for you.
@jose-cazarin, if it still doesn’t work with your setup, could you please share your project type (MSBuild/Make), the build configuration (build on target, or using a cross-toolchain) and share the code that triggers the problem so that we could recheck it on our side?No problem, we have added a per-memory setting that controls the generation of the .bin files.
Please try this build: VisualGDB-5.5.2.3384.msi
Hi,
VisualGDB 5.5 Preview 1 could indeed show the VisualGDB Build window for non-VisualGDB builds. We have already fixed it in our development branch (you can try this build: VisualGDB-5.5.2.3372.msi).
The GDB Session window should only appear for VisualGDB-based debug sessions. If not, please try closing it manually and describe the exact steps to reproduce the issue from opening Visual Studio to triggering the problem. We are asking for this because the behavior is likely caused by some rare combination of settings or actions and we are not able to guess it, or suggest anything meaningful without knowing what exactly you are doing to trigger the problem.
