Forum Replies Created
-
Posts
-
Based on what we can see in this thread, this configuration triggers some bugs in KGDBoE (module that supports kernel debugging over network). If you would like to get this working, you would need to debug KGDBoE itself and understand why it is not working. VisualKernel merely provides a GUI on top of KGDBoE and cannot automatically fix the way it works.
Thanks for reporting this. We will monitor the feedback from our paid users, and will consider investigating it further if they confirm it.
Thanks for reporting this. We will monitor the feedback from our paid users, and will consider investigating it further if they confirm it.
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.
