[support]

Hi,

Sorry, this is not supported yet, although we are researching Valgrind support and will be adding some level of integration with it into VisualGDB 5.3.

[support]

Hi,

Thanks, we have replied with the address.

[support]

Hi,

Thanks, we have updated the description.

[support]

Hi,

Sorry, translating our GUI to multiple languages would drive the VisualGDB price sky high, so we have to stick with English-only interface.

[support]

We are gradually switching the GUI over. Each new release has a few more dialogs and settings pages converted, so it gets better each time you update.

[support]

Hi,

Thanks, the session does not look out of the ordinary indeed. One last advice would be to try setting Advanced GDB Settings -> Startup and Exit -> When the debug session is ending -> Explicitly kill the process. This should force gdb to explicitly terminate the target process when exiting.

[support]

Hi,

The custom post-debug steps are only supported on the Custom edition of VisualGDB and higher (see the feature matrix). If you have purchased a lower edition, this feature would not be available.

You can always upgrade your edition at https://sysprogs.com/splm/mykey.

Another alternative would be to try understanding why gdb is not terminated properly. Please try enabling GDB logging via VisualGDB Project Properties and check the last gdb command that gets executed before GDB hangs.

[support]

Hi,

Thanks for reporting this, we have fixed the missing “additional linker inputs” handling in this build: http://sysprogs.com/files/tmp/VisualGDB-5.2.16.1483.msi

The behavior with additional linker inputs is by design as both library names and additional linker inputs are saved in the same field in the QT project file. As names with spaces are generally not supported very well by GNU tools, VisualGDB does not support them either (you can still use them by editing the Qt project file manually, but VisualGDB GUI won’t show it correctly).

 

[support]

Hi,

Please contact our support with the details of your license key and we will help you resolve this.

[support]

Hi,

No problem, this should help us diagnose it quickly. Please contact us via the support form on our website to arrange the shipping.

[support]

Hi,

It looks like a bug introduced by the MinGW path translation. If you have the full msys, setting USE_DEL_TO_CLEAN to 0 should be the easiest fix.

[support]

Hi,

You can check for __GNUC__ or other GCC macros.

[support]

Hi,

Our support for AVR devices is somewhat basic as they are much less popular than ARM-based devices like STM32.

VisualGDB actually relies on an open-source tool called AVaRICE in order to handle the low-level communications. According to this thread, AVaRICE should be able to support Atmel ICE, although we have not tested it explicitly and cannot guarantee it. We would recommend experimenting with the AVaRICE command line to see if it gets to work.

If you encounter any problems, feel free to post the details here and we will try to help, but unfortunately we cannot give a 100% guarantee that Atmel ICE will work.

[support]

Hi,

Looks like your toolchain might be corrupt. Please try locating the libstdc++.so file mentioned in the error message and check its contents. If it looks like a text file containing the path to another file, it could be an incorrectly unpacked symlink. In this case please try copying the target file over that libstdc++.so file.

[support]

Hi,

This could happen if the file is not explicitly included in your VC++ project. Could you double-check that it’s explicitly there? If not, would you be able to reproduce the problem on a basic “hello, world” application and send it to us so that we could investigate this further?

[Author]

Posts