Forum Replies Created
-
Posts
-
Hi,
No problem. The easiest way to do this would be to use Debug->Quick Debug command (requires Custom edition) and select:
- Target: Linux system
- Use a cross-compiler on the Windows machine
Then VisualGDB will let you choose a toolchain containing the gdb. Simply click “locate a cross-toolchain by finding its gdb.exe” and point it to your gdb executable.
If you use regular VisualGDB projects to build your project, we can help you configure them as well. Do you use the regular “start a new instance” setting?
Hi,
A cross-gdb is a Windows build of gdb targeting your Linux machine. You can normally obtain it by downloading the sources for the same version of gdb as your Linux VM uses (applying Debian patches if relevant) and building it on Windows from a MinGW shell (you would need to specify target and the target options to 100% match the configuration of your Linux gdb).
As a result you will get a gdb.exe that can run directly on Windows and communicate to the remote target via the gdbserver protocol.
You can also try using one of the gdb binaries from this archive, however they may end up being incompatible with your target due to incompatible flags.
Hi,
It’s hard to say what could be causing it without knowing the context (it could be a typo in the device library, incompatible setting, old gcc or a missing #define somewhere). Please let us know which device family you are using and attach a screenshot of the source file with the line causing the error and we will help you resolve this.
Hi,
VisualGDB itself does not have any limits on command line lengths (it actually uses response files to avoid any implicit limits set by Windows).
The behavior you are experiencing might be caused by the WinForms text box control used across VisualGDB settings. Please try using the VS project properties instead (or edit the .props file manually).
Hi,
Thanks for the screenshots. At the first glance, the 2 projects look equivalent. Can you confirm that opening one of them with VS2017 works and the other one opened with VS2017 fails?
The message box you attached looks like it’s produced by Visual Studio before and VisualGDB logic gets triggered, so most likely it is caused by either corrupt MSBuild platform definition, or some installation-related problems. Uninstalling and installing back VisualGDB (and VS if this doesn’t help) might resolve this.
Hi,
Sorry, not currently. VSCode is a completely different product from the regular VS and supporting it would essentially mean creating a completely independent plugin re-implementing most of the functionality using a different stack.
Hi,
No problem. Regarding the environment, we usually recommend choosing “fix value” if you are unsure. This works around the case where some PATH variables are applied for regular console sessions, but not for ‘command’ sessions used by VisualGDB to launch the debugger, leading to hard-to-trace “library not found” errors.
Hi,
Most likely your toolchain is not compatible with the target system image.
Please ensure you are using EXACTLY the same SD card image as listed for your toolchain on the toolchains page: http://gnutoolchains.com/raspberry/Hi,
Please try installing the latest v5.3 Preview 8. Then click at the ‘show details’ hyperlink in the exception window and post the details here. This should help us understand what could be causing it.
Another quicker solution would be to simply re-create the project via VisualGDB Project Wizard and compare the settings with the original project. Most likely some of the settings in the .vcxproj file got accidentally replaced by an empty string.
Hi,
This feature was added to VisualGDB 5.3 and is not available in v5.2. Please ensure you install the latest preview build.
Hi,
No worries, good to know you got it to work. If you encounter any further problems, feel free to start another topic.
Hi,
According to our records, your technical support as expired. Please renew it via https://sysprogs.com/splm/mykey and we will be happy to help you.
Hi,
Yes, this is a known limitation of Linux systems, although it’s very well-known and relatively well-documented, so as long as you can find someone with basic Linux knowledge, they should be able to figure it out quickly.
Hi,
The problem could also be caused by Visual Studio having some files in the toolchain folder open (e.g. the debugging plugin).
Please try updating to Preview 8 (your log mentions version 5.3.6 that is Preview 6). It includes a better toolchain updating mechanism that first removes the previous toolchain folder and only then installs the new toolchain.
Hi,
Please try searching the library files (.so) for the ones defining the missing symbols. Then ensure that the linker can find them.
Sometimes the .so files contain a link to another file instead of the actual library (you can see this in text editor). If this is the case for the .so file containing the missing symbols, please ensure that the target linked from the original .so file exists. If it’s using syntax like /usr/lib/… please replace it with =/usr/lib/… so that the linker can automatically substitute sysroot.
