Forum Replies Created
-
Posts
-
Sorry, based on what we see, you do not have a valid license and tried tampering with the activation system. We will not be able to help you.
VisualKernel is a much more niche product that VisualGDB. It solves a narrow subset of problems that are relevant to a smaller number of users, hence it is not updated as regularly.
Based on the feedback we receive, many users would appreciate a direct way to run VisualKernel on Linux and not have to install Windows + Visual Studio in a virtual machine.
We are working on a technology that will allow doing that, while retaining all advanced features (e.g. tracing). It will be first integrated into VisualGDB and another brand-new cross-platform product, and will then make its way into VisualKernel. Until then, we are not planning to do any major VisualKernel updates.
Please refer to the following thread: https://sysprogs.com/w/forums/topic/visualgdb-ui-refresh/
VisualGDB is already integrated into the Visual Studio theming engine. It picks up colors for common controls to match what Visual Studio itself uses, and follows the dark/light themes. Hence, when the new UI is selected, most of the VisualGDB controls should automatically pick up most of the new colors. We will then monitor the popularity of the new GUI, and will gradually resolve the remaining inconsistencies over future releases.
As for redesigning all of our GUI using a new design system, it would not be very practical, as our users would rather prefer new functionality and compatibility with the latest devices, than a lengthy redesign bringing no new functionality, while delaying functional improvements.
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/
