[support]

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;
}

[support]

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.

[support]

Please try this build: http://files.sysprogs.com/tmp/VisualGDB-5.0.13.470.msi

[support]

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.

[support]

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/

[support]

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.

[support]

Can you try uninstalling VisualGDB, restarting and installing it again? If this does not help, please let us know which other VS extensions you are using.

[support]

Good to know you got it to work. If you encounter further problems with your activation, please contact our support via email so that we could look up your activation status and see if the problem is on our side.

[support]

You can synchronize the sysroot via VisualGDB Project Properties -> Build Settings page. Starting from VisualGDB 5.0 Beta 4, VisualGDB will remember the custom directories used for the last sync.

[support]

This looks like a gdb bug. Please update your gdb to a newer version. If you are using a Linux one, you can build a new one from sources by downloading the sources, unpacking them and running “./configure && make” in the source directory. Then specify the built gdb binary in VisualGDB Project Properties and VisualGDB will use it to debug your projects.

[support]

You can achieve this by adding a section to the linker script (see this post for details) and then using a script to convert your binary file to a .c file like this:

__attribute__((section(“.mysection”))) const unsigned char MyFile1[] = {0xXX, 0xYY, … };

Do not forget to use the KEEP statement in the linker script file, otherwise the MyFile1 variable will be optimized out.

You can define labels before and after the section contents and then reference those labels similar to _sdata and _edata (see the startup file for an example).

You can also use objcopy as described here to convert your binary files to object files. This will be equivalent to making a .c file as described above and compiling it to a .o file.

[support]

Which toolchain are you using? The Sysprogs ARM toolchain should enable semihosting by default. The GNUARM toolchain needs enabling it by specifying a spec file. The latest VisualGDB 5.0 beta 4 can automatically detect the GNUARM toolchain and provide a GUI option for enabling semihosting.

[support]

Hi,

Yes, in the latest VisualGDB 5.0 Beta 4 you can change it via VisualGDB Project Properties.

We even added a button that automatically copies the default linker script to the project directory, opens it in VS and updates the project to use it.

[support]

Hi,

This is the directory where the Android Studio/gradle expect the native files. The problem is that the native support there is currently broken, so when Gradle tries to build the native files, it could:

1. Generate a Makefile that won’t build on Windows due to problems with parsing Windows-style paths
2. Strip the symbol information from the built libraries, making the debugging impossible

The exact gradle bugs change from version to version, so our current recommendation is to keep the source files in the app\jni directory and let VisualGDB handle the build. This will ensure that you won’t get strange build errors and that your symbols will be generated correctly. As soon as the Gradle support for native symbols becomes stable, we will update our tutorials to use the recommended paths.

[support]

This would cause several bugs with the NDK tools. If you don’t want to move the actual files, you can create a symbolic link using the mklink command, i.e.

mklink /d C:\Users\nzmora\AndroidStudioProjects\CameraProcessor\app\jni C:\Users\nzmora\AndroidStudioProjects\CameraProcessor\app\src\main\jni

[Author]

Posts