Forum Replies Created
-
Posts
-
Is it the toolchain that came with VisualGDB (http://gnutoolchains.com/arm-eabi/) or have you installed it separately? Could you attach your stm32.xml file that shows the current toolchain configuration?
Hi,
Thanks for reporting this. Looks like the gdb error message changed in one of the recent versions. We have updated our knowledge base so it should now warn about the missing file.
Hi,
Please try following the Cocos2d-x VisualGDB tutorial here: http://visualgdb.com/tutorials/android/cocos2dx/simplegame/. It contains all necessary steps. If it does not work for you, please let us know.
Hi,
Are Source.cpp, Source.h and ObjectClass.h in the same directory? If not, it is by design that IntelliSense only searches the include directories and not every possible directory.
If you have imported a custom project, most likely your build system adds those directories to the include directory list explicitly, so build can find them. VisualGDB can only import those directories automatically if you are using VisualGDB-generated Makefiles (or CMake/QMake files) with known structure, otherwise you need to specify the include directories manually like you just did.
Hi,
Thanks for reporting this, we have fixed it in VisualGDB 5.0R2: http://visualgdb.com/download/
Hi,
Sorry to hear that it did not work for you. We have rechecked everything and published a detailed tutorial showing how to debug Gradle flavors here: http://visualgdb.com/tutorials/android/astudio/flavors/
We have also released VisualGDB 5.0R2 that contains several fixes related to project configurations in VS2015. Please update your VisualGDB before trying the tutorial: http://visualgdb.com/download/
If this still does not work, please share more details of the problem here or via our support email. We certainly did not intend to break this functionality in v5.0, so if it is broken in any way, we will certainly fix it.
Hi,
VisualGDB path mappings only affect the error messages and paths reported by the debugger; they do not change the inner logic of the toolchain.
You can use the ‘=’ prefix to specify paths relative to the sysroot, e.g.:
GROUP ( =/lib/libc.so.6 =/usr/lib/libc_nonshared.a AS_NEEDED ( =/lib/ld-linux-armhf.so.3 ) )
If you need to change the files often, the easiest solution would be to make a simple script for adjusting the paths in the newly copied files. It should be doable with a few regular expressions…
Please try replacing the msp430.dll file in the toolchain bin directory with the latest version from TI. This should ensure that it is 100% compatible with your hardware.
Please try calling initialise_monitor_handles():
#include <stdio.h> extern "C" void initialise_monitor_handles(void); int main(void) { initialise_monitor_handles(); printf("test\n"); return 0; }Please follow the Qt cross-toolchain tutorial for Raspberry Pi: http://visualgdb.com/tutorials/raspberry/qt-cross/
Simply use the Beaglebone-Debian toolchain instead of the Raspberry Pi one and you should be able to build your project.
Please try this build: http://files.sysprogs.com/tmp/VisualGDB-5.0.13.470.msi
Hi,
Thanks everyone, we got a repro. Looks like the final build of VS2015 initializes editor extensions in a different way causing a problem with VisualGDB. We will release a hotfix within the next 24 hours.
If you want to create a barebone embedded project, please follow this tutorial: http://visualgdb.com/tutorials/arm/legacy/
If you want to create a project for Embedded Linux, please follow our Raspberry Pi tutorial: http://visualgdb.com/tutorials/raspberry/
Hi,
Sorry for the late reply. We have looked into it and it looks like some internal VS bug, as we explicitly specify to use the default background color. We will be investigating this further and adding the workaround to it to VisualGDB 5.1.
