[ket]

Hi,

We have tried to replicate your scenario with no success.

Is the include file with inline functions part of your project? Do you have several include files with the same name in the project directory on you Linux machine?

[ket]

Hi,

You can try adding the QMAKE_LFLAGS variable to debug.pro, this variable is used to specify flags to the linker. You can try using it instead of specifying the libraries in the LIBS variable.
Begin the library list with -Wl,–start-group and end it with -Wl,–end-group, the libraries should be declared in between as usual for the LIBS variable.

The libraries specified in LIBS are specified differently from LIBRARY_NAMES, the library names should be prefixed with -l. The LIBS variable is also used to specify the library paths, those should be prefixed with -L. If you add libraries and library paths from VisualGDB Project Properties, then the correct syntax is used automatically for LIBS.

[ket]

Hi,

It looks to be a namespace issue, the vector and string are not displayed with nice visualizers because gdb reports their namespaces wrong i.e. not as std. Normally the type would always be referred with the full namespace. This could be a toolchain issue or maybe something wrong with namespaces in your code.

The vector type is reported as vector only not as std::vector. Is the std namespace mapped to an empty namespace? We do not feel comfortable always using an std::vector visualizer for any vector type without a namespace, it can give issues with other libraries vector types.

The string is reported as Util::string not as std::string. Again we cannot add support of a std::string visualizer to Util::string, as the structure of Util::string would normally be anything but std::string.

We could give you the source of STLVisualizers, the plugin that handles STL visualization that you could adjust it for your toolchain if you are interested.

[ket]

Hi,

When you hover over st, what is VisualGDB calling from gdb and what is its response (also in the GDB Session window)? Is it the same as the command you run manually?

[ket]

Hi,

Normally VisualGDB does support good visualizers for STL containers. Which version of VisualGDB are you using and which project type do you have (e.g. Linux, Embedded etc.)?

[ket]

Hi,

Which headers do you mean here? Usually the headers in you project are included by relative paths anyway.

[ket]

Hi,

Are you looking into kernel sources? What libraries and includes are you using i.e. how could we reproduce the same errors on our side?

[ket]

Hi,

The biggest difference between armv6 and armv7 is hardware floating point support. armv6 has it but armv7 does not and it can have NEON registers instead.
GCC itself is usually the same, so to optimize for armv7 try adding the following to CFLAGS to specifically target armv7:

-march=armv7

You can find the documentation on ARM GCC flags here.

[ket]

Hi,

In general, all the build actions from Qt Creator’s compile output should be replicated in a custom project in VisualGDB to be able to build. Post a copy of the build output from Visual Studio here, so we can see what the errors are.

For debugging, you can also use the APK file Qt Creator creates. Simply use the aligned APK file with the “Android->Debug a Custom APK file” feature. There is a tutorial on this feature here.

[ket]

Hi,

Thanks for the suggestion. We will considering adding this feature.

[ket]

Hi,

We currently do not support compiling single files. We are considering adding support for it, but as it is a complicated feature to support for some of the project types, we may add support for it gradually.

As a workaround you could disable makefile auto-updating of SOURCEFILES temporarily (remove the #VisualGDB: AutoSourceFiles line from the Makefile) and use the Makefile to compile only the files you add to SOURCEFILES.

[ket]

Hi,

You could try to use the Raspberry Pi toolchain as it is also Debian/Wheezy based, but definitely resynchronize the sysroot before building with the toolchain. You can resynchronize the sysroot in VisualGDB Project Properties on the Makefile settings page.

[ket]

Hi,

For the include directories you do not need to specify $(ProjectDir), the subdirectory names are enough. Everything in Makefile settings gets put into the Makefile, so using macros there will not work as make will not be able to translate them (unless they are environment variables that are also passed to make). The include directories should be updated automatically based on the include directories, unless the toolchain test fails and the new settings are not committed.

Currently, the IntelliSense directories page allows entering directories only. Entering paths containing macros directly to IntelliSense could work. We will consider adding support to macros also from the IntelliSense directories page, at least in the case of local IntelliSense directories.

[ket]

Hi,

You can add a definition of __null for IntelliSense in the gcc_compat.h file located in the VisualGDB installation directory.

Normally make should compile only the changed files when compiling the project. If you are changing files included in many other files, then of course those files too need to be recompiled.

[ket]

Hi,

Normally you should only edit settings in VisualGDB Project Properties. If you edit settings on the Makefile settings page your changes will be saved into the Makefile and the settings tested. By adding include directories there, also IntelliSense directories get set properly. To include source just add it to the project.

Visual Studio specifies the __cplusplus flag in IntelliSense. Add a a work-around to your main header file or each source file as follows:

#ifdef _MSC_VER
#undef __cplusplus
#endif

[Author]

Posts