[support]

Hi,

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

 

[support]

Hi,

Did you get any toolchain testing errors while creating your project? Normally IntelliSense is configured based on the results of a toolchain test.

[support]

Hi,

We expect a preview build this week. We are going to support the latest version from github.

[support]

Hi,

Here’s an example of modifying the Makefile to copy your .so file in the ..\AllLibraries directory (it assumes that you are building on Windows with a cross-compiler):

../AllLibraries:
    mkdir ..\AllLibraries

ifeq ($(TARGETTYPE),SHARED)
$(BINARYDIR)/$(TARGETNAME): $(all_objs) $(EXTERNAL_LIBS) ../AllLibraries
    $(LD) -shared -o $@ $(LDFLAGS) $(START_GROUP) $(all_objs) $(LIBRARY_LDFLAGS) $(END_GROUP)
    copy /y $(subst /,\,$@) ..\AllLibraries\$(notdir $@)
endif

VisualGDB does not overwrite the Makefile, it carefully adjusts parts of it (e.g. the SOURCEFILES assignment line and the lines below the #VisualGDB: GeneratedRules marker).

Normally VisualGDB should add the -Wl,–rpath=’$$ORIGIN’ flag to linker flags and that should add an attribute to the linked file telling the library loader to check the directory of the executable for missing library dependencies. Do you see this flag in your build log?

[support]

Hi,

Thanks for the log files. It looks like Qt Creator is using Python extensions to extract meaningful values from the STL variables. VisualGDB does the type matching on the Visual Studio side in order to support gdb builds without Python support. As a side effect of it, it cannot automatically resolve typedefs without issuing further commands.

The upcoming VisualGDB 5.1 supports Natvis, so we could add an extension to its format in order to explicitly specify typedefed types and map them to STL containers. Would that be a reasonable option?

[support]

Hi,

Please try using the Embedded Memory Explorer to see what exact code occupies the IRAM memory. Then try moving some of it to FLASH or modify the linker script to place the default code sections to FLASH instead of IRAM (that may impact performance/stability).

[support]

Hi,

We are planning to add mbed support in the next preview build of VisualGDB 5.1. We will be adding a tutorial in the next few weeks.

[support]

Hi,

There was a bug in our latest Raspberry Pi toolchain. Please re-download the toolchain from http://gnutoolchains.com/raspberry/

[support]

Hi,

The binary size explains the delay. You can add a custom post-build step to deploy your binary and disable the automatic deployment in Debug settings. As the build process always runs in the background, this will move the deployment to the background as well.

Regarding “searching for a matching source file”, VisualGDB does that when it’s searching for a .cpp file that includes the .h file being opened. Normally it quickly scans all source files for unconditional include directives and picks the first matching one, however if none of the files include your header file unconditionally, VisualGDB will try fully parsing some of the files to find which of them actually includes the header. Is your header directly included from one of the files? Is the include directive surrounded by #ifdef or #if?

[support]

Hi,

Normally you need to edit the linker script and use the “section” attribute to place code and data into a specific memory. You can read more in this topic. If it does not help, please give us an example of what you are trying to do so that we could give a better suggestion.

[support]

Hi,

This means that you are missing the reference to the static library (should be called libPoco.a or something similar). Note that if you have just downloaded the sources from Internet, you need to configure and build the library according to the instructions provided by its vendor. This will produce the .a file that you can reference from VisualGDB Project Properties (normally add the directory with the .a files to the Library Directories and add the library name without the ‘lib’ prefix to the Additional Libraries).

[support]

Hi,

Qt creator may be explicitly querying the type of each variable or may be using some GDB extension that VisualGDB does not support.

We can investigate this during the v5.2 release cycle, however if you could obtain a full GDB command log from Qt creator (if it supports creating such logs or shows the executed GDB commands somewhere), we may be able to include a fix in the upcoming v5.1 release.

The breakpoint problem does not sound like any known issue, can you reproduce it on a “Hello, world” project and send it to us so that we can see what’s happening? You can also run the “info breakpoints” command in the GDB Session window to find out the address where the breakpoint was put and then use the disassembly window to understand whether this address is correct and actually contains the constructor code.

[support]

Hi,

Please right-click on your project in Solution Explorer, select “VisualGDB Project Properties”, go to the Makefile Settings page and add the include directories there.

Let us know if you run into further problems.

[support]

Hi,

Yes, we specifically designed the Clang engine to run in a separate process so that any crashes inside clang don’t affect your Visual Studio.

Are you able to reliably reproduce some of the crashes and send us the repro instructions? If it only happens with your project, we can send you a debug build of the engine so that you could create a dump file.

We have easily fixed previous crashes like that, so your crash dumps are more than welcome.

[support]

Hi,

Yes, that would work. You can also add a command to the Makefile to copy the built library to a common output directory after it is linked. Let us know if you need a detailed example on that.

[Author]

Posts