[support]

Hi,

Oops, sorry for that. Please provide us with the following information to pinpoint your problem:
1. Does the problem occur on every debug session? If not, how frequently does it occur?
2. Does the “timeout” dialog automatically disappear after 1-10 seconds? If this is a bug of LibSSH2, we have a safety mechanism that should automatically resolve such hanging within 1-10 seconds.
3. Does invoking “info target” manually via the SSH Session window cause the same bug?

[support]

Hi,

Currently this is not possible directly. You can put a breakpoint at the end of the main() function to achieve a similar result.
Using scanf() or cin should normally work. Please send us an archive with an entire test project (including the source code and the Visual Studio project files). If this is a bug of VisualGDB, this will help us to reproduce and fix it.

[support]

Hi,
Please go to Visual Studio Configuration Manger (click on the debug/release switch on the toolbar) and remove the “build” flag for the projects you don’t want to build.
Note that you can create as many solution configurations as you want all having different project sets enabled.

You can also configure Visual Studio to prompt before auto-building the projects when you start debugging.

[support]

Hi,

Normally the Python include files are located in a Python-version subdirectory (e.g. /usr/include/python2.7/Python.h). Thus you need to add it to additional include path.
This can be done by setting the INCLUDE_DIRS variable inside flags.mak. E.g.:

INCLUDE_DIRS := /usr/include/python2.7

If you are using a cross-compiler, the path will be:

CROSS_SYSROOT := C:/SysGCC/raspberry/arm-linux-gnueabihf/sysroot
INCLUDE_DIRS := $(CROSS_SYSROOT)/usr/include/python2.7

[support]

Thanks for the kind words. We do our best here at Sysprogs to make complex debugging scenarios easy and enjoyable.

As for the cross-compiler, both options have pros and cons:
• Building big projects with a cross-compiler is usually faster, as your computer is much faster than the Raspberry PI box. However, it will require synchronizing includes/libs and might cause strange bugs if the libraries inside the cross-compiler and on the Raspberry PI get out of sync.
• Building and running GDB directly on Raspberry PI should work out-of-the-box for most cases, but it may become annoyingly slow for big projects with many source files.
• If you are building an app that comes with a configure script that should run on Linux, you cannot use the cross-compiler unless you want to set the MSYS environment manually (which will still impose some limitations).

Bottom line, VisualGDB fully supports both options, the choice is yours depending on what’s more important to you…

[support]

Thanks for this bugreport. Looks like it’s our bug related to using the build server.
Please use SSH instead. The SSH support is a new feature introduced in VisualGDB 3.0 and we haven’t updated all our tutorials yet.

Edit: fixed the bug and replaced the Beta2 distro. Thanks again for reporting it.

[support]

Hi,

When using a cross-compiler for Raspberry you need to copy any additional include files from the /usr/include on the Raspberry box to C:SysGCCraspberryarm-linux-gnueabihfsysrootusrinclude. Then the toolchain and the IntelliSense will recognize them correctly.

You can use SmarTTY, our free SSH client to quickly download the entire include directory into the toolchain directory.

[support]

Hi,

Thank you for your bugreport. Please provide us with more information so that we could pinpoint the problem:
1. Which OS/VS version are you using?
2. Are you selecting the default settings or changing something (e.g. setting up SMB shares)?
3. Is your WIndows project directory writable.
4. Is your Linux project directory writable?
5. Are the remote file/directory browse dialogs working in the wizard (e.g. when you try to change the source directory)?
6. If you enable the advanced wizard mode and disable importing of IntelliSense directories, will the problem still persist?

As a last resort, please set the following registry value:
HKCUSOFTWARESysprogsVisualGDBSettingsExceptionReportDir = c:tempvgdb

Ensure that c:tempvgdb exists and is writable by the user account used to start Visual Studio.
Then try reproducing the problem. If VisualGDB encounters any internal errors, it will create report files in c:tempvgdb. Please send us those for further diagnostics.

[support]

Please try VisualGDB 3.0 Beta 1. The problem is fixed there.

[support]

Hi,

Thanks for reporting this. Fixed in Beta 2.
http://www.visualgdb.com/download/

[support]

Hi,

Could you please send us your .vcprojx file and the .filters files so that we could reproduce and fix your problem?
There was a bug in v2.7 that could cause this, however it was fixed in v3.0.

[support]

Hi,

Yes, the bug is caused by the ‘ps’ command producing slightly different output from the one on most of the Android devices.
We have fixed this in the upcoming VisualGDB 3.0 release. We are planning to release the beta (also supporting vs-android integration) at the end of this week.

[support]

Hi,

Permission granted. If you need an official document, email sysprogs@sysprogs

[support]

Hi,
Done. Please download VisualGDB 3.0.

[support]

Hi,

You can easily use VisualGDB with the free CodeSourcery Lite toolchain.
Please try this instructions on setting up the toolchain: http://www.lpcware.com/content/project/lightweight-ip-lwip-networking-stack/building-lwip/embedded-artists-lpc1788-board/gn

[Author]

Posts