Forum Replies Created
-
Posts
-
Hi,
You can try using the Quick Debug feature. You can point it to the gdb executable and the debugged executable on the FreeBSD machine, and then configure source path mappings to help it locate the sources on the Windows machine.
That said, FreeBSD debugging is not 100% compatible with Linux and we do not regularly test VisualGDB with FreeBSD due to a much smaller number of users. Most common functionality should work fine, but there might be glitches here and there.
It looks like your technical support period has expired. We would be happy to help you, however we would kindly ask you to renew your technical support on the following page first: https://sysprogs.com/splm/mykey
It looks like your technical support period has expired. We would be happy to help you, however we would kindly ask you to renew your technical support on the following page first: https://sysprogs.com/splm/mykey
Sorry, this doesn’t look like a VisualGDB-specific issue. Please refer to the GCC documentation for more details.
It looks like your technical support period has expired. We would be happy to help you, however we would kindly ask you to renew your technical support on the following page first: https://sysprogs.com/splm/mykey
No problem, we have just released an repackaged version of the latest TI toolchain that should work out-of-the-box with VisualGDB. You can update it via VisualGDB Package Manager or here: https://gnutoolchains.com/msp430/
We don’t really have any special code for calling a particular shell. It’s up to the Make executable and we don’t have much insights into it. CMake+Ninja (or MSBuild) works way better and way faster, so we recommend using it instead.
Hi,
This could be due to a bug in the GNU Make where it sometimes just lock up on multi-core systems. So, normally, we would advise using CMake + Ninja or MSBuild instead. These systems are much more modern and work way better.
If you have to use GNU Make, you may need to experiment with other similar projects to see what exactly triggers the lockup.
Thanks for renewing your support.
Please follow the steps on this page to troubleshoot VisualGDB loading problems: https://visualgdb.com/support/loadfail/
If nothing helps, please do the following:
- Completely uninstall VisualGDB. If the uninstallation doesn’t work, see this page. Verify that the C:\Program Files (x86)\VisualGDBÂ folder has been deleted by the uninstaller.
- Completely uninstall Visual Studio. Verify that the Visual Studio folder has been deleted, and delete it if necessary
- Reinstall Visual Studio (C# and C++ workloads).
- Reinstall VisualGDB.
Installing an unsupported version would normally show a very straight-forward error message and point you to the list of the old versions. So the problems must be caused by something else.
Our best guess is that during the 3 days of troubleshooting you ended up breaking some global settings. We were not with you for these 3 days, so we don’t know what you changed and do not have any suggestions beyond resetting as much of the environment as possible.
You can view the status of your support, manage your renewals and upgrades here: https://sysprogs.com/splm/mykey
If you you would like us to point out exact troubleshooting steps, we would kindly ask you to renew your support. Otherwise, you can just try googling it. We have a lot of documentation describing various troubleshooting scenarios.
This sounds like you have accidentally broken something while trying to uninstall/reinstall (edited some files?). It doesn’t sound like any known issue. It could be that the older VisualGDB is not compatible with your Visual Studio or some other part of your setup.
Normally, completely uninstalling VisualGDB, Visual Studio, deleting all directories and reinstalling everything back should help.
