[support]

Hi,

Unfortunately this is not possible with the current model. VisualGDB tries to simplify editing the settings, so it relies a lot on the ‘current project’ concept when displaying the properties (e.g. substitutes variables). To support editing multiple projects at once, we would have to add a completely different mechanism of editing them, and that is currently a too big investment for us.

You could try referencing environment variables from your projects using the $(VarName) syntax. Alternatively you can make a mini-tool for editing the properties you want. VisualGDB stores its properties in XML files with .vgdbsettings extension. Those files contain XMLSerializer-generated objects from the VisualGDB.exe assembly, so you could easily automate changing them. Let us know if you want some code examples.

[support]

Hi,

Yes, this is possible. The easiest way would be to edit the Application.mk file and replace APP_ABI := all with APP_ABI := armeabi.
You can also try VisualGDB 4.2 beta 1 that allows selecting ABIs in the project wizard.

[support]

The GCC compiler does not have a concept of “stack size”. It uses all space between the end of data and _estack as the stack. If you want to reserve a certain amount for the stack, you can define an array of that size, put it to a separate section and modify the linker script to place it after the data. In that case if the overall amount of used memory exceeds the device SRAM size, you will get a linker error.

[support]

Hi,

In order to replace the newlib’s implementation of _write() with your own one you would need to recompile newlib itself. If you don’t want to do it, you can hook it dynamically:

static int my_write(struct _reent *, _PTR, const char *buf, int len)
{
...
}

int main()
{
stdout->_write = my_write;

stdout->_flags |= __SNBF;

printf("Hello...");

}

[support]

Hi,

Based on our quick tests, clang produces executables that can be easily debugged with gdb. As lldb is not backward-compatible with gdb/mi and uses its own API, support it would be quite an investment. If you could give a good overview about the advantages it would have over using gdb for debugging llvm-compiled code, we could see if we could support it soon.

[support]

Hi,

You can always revert back to VisualGDB 2.x (just replace the version number in the download URL on our website). Additionally you can backup the following directories:
%LOCALAPPDATA%VisualGDB
%APPDATA%VisualGDB
Your android tools directories
Your project directories
Registry ({HKLM, HKCU}SoftwareSysprogsVisualGDB)

VisualGDB does not store anything critical anywhere else, so if things go wrong, you can simply recover those directories.

[support]

Yes, simply add -Wl,-Map=output.map to LDFLAGS. Actually, can you send both binaries (the ones with and without a reference to libmmal_vc_client) to our support email? We should be able to see the difference from a quick look at the section dump and some disassembly.

[support]

Sorry, we don’t have a specific guide for those OSes. As VisualGDB uses GNU Make as the underlying build system, you can follow the FreeRTOS manuals on creating a Makefile and then simply import the project into VisualGDB using the “Import Project” setting in our wizard. If your project can be built with command-line Make, VisualGDB will easily work on top of it.

[support]

Hi,

Visual Studio 2010 has very limited support for C++1x, so IntelliSense errors are fully expected in this case. On a long term we are working on resolving this by providing an independent IntelliSense engine. On a short term you may be able to work around it by undefining some of the C++1x defines for IntelliSense:
#ifdef _MSC_VER
#undef …
#endif

The list of C++1x-specific defines can be found by comparing gcc_Debug.h before/after enabling C++1x support.

[support]

Hi,

Visual Studio is only involved in IntelliSense; compilation is fully performed by gcc using the standard library that comes with gcc. Please verify that the implementation of shared_ptr that comes with your gcc version has the operator-> defined.

[support]

Hi,

There is actually a bug in VisualGDB 4.1 that prevents it from automatically disabling the clang-incompatible options. This will be resolved in the upcoming VisualGDB 4.2. As a workaround please continue creating the project, then edit the debug.mak/release.mak files:

1. Remove “-Wl,-gc-sections” from LDFLAGS
2. Remove values of START_GROUP and END_GROUP

[support]

Yes, if you are using Custom or Ultimate editions. Use the “Custom build steps” page in VisualGDB Project Properties.

[support]

Hi,

Forcing to link against a library with no actual functions imported would not solve the problem if some component is missing. Please try examining the symbol table of the module that links against the library correctly (readelf -s ), find out which functions are imported from libmmal_vc_client.so and then see why they are not imported on the version built with the cross-compiler (enable creation of a map file to see details about functions).

[support]

Hi,

In order to automatically get stopped in main(), start debugging by pressing F10 (step into new instance), not F5 (start new instance).

[support]

Hi,

We are putting –start-group/–end-group around all files because the -lXXX form can refer to either libXXX.a or libXXX.so depending on what is available in the library directories. We also tested it with shared libraries and did not encounter any problems.
Could you please share a log showing the command line and the build error you encountered? If we could reproduce it on our side, we should be able to provide a solution that works for both cases.

[Author]

Posts