Forum Replies Created
-
Posts
-
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.
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.
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.
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.
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.
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.
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.
