[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.

[support]

Hi,

Thanks for the details. The message box was originally used to provide information about the exact signal gdb reports, however it does indeed look redundant when the only information it contains is the SIGINT name. We will add an option to filter it out in the next release.

Regarding your gdb log, it looks like you are not setting any breakpoints. The only -break-insert command sets a breakpoint in main() and this breakpoint is successfully hit later. Could you please share a screenshot of your breakpoints? Are you setting them before running your firmware or when it’s already running?

[support]

Hi,

The error with ‘dat.getContentType()’ is by design, as it literally means ‘invoke the getContentType() method of the dat object’ and as the pointer itself does not have a getContentType() method, it produces an error.
The error with the -> form means that the smart pointer you are using does not define an overloaded “operator->”. Please check the source code of the standard library you are using whether the operator is defined. You can read more about overloading the -> operator here: http://www.tutorialspoint.com/cplusplus/class_member_access_operator_overloading.htm

[support]

Hi,

It’s a known bug that will be fixed in the next maintenance release. As a workaround, please switch the GDB mode to “Custom mode”, then click “customize” in the gdbserver command editor and specify your variables there.

[support]

Hi,

We are not targeting Atmel devices because Atmel provides their own IDE (Atmel Studio). However you can add new devices to VisualGDB by creating a board support package. Essentially you will need the following information:
1. GCC command-line switches for your target (typically -mcpu=cortex-XXX and various definitions).
2. a linker script for your target
3. startup code provided by the device manufacturer.

All those are typically present in the GCC sample projects provided by device manufacturers. In order to integrate these settings into VisualGDB you could try 2 different approaches:
1. Select “Specify flags manually” in the VisualGDB Project Wizard
2. Create your own BSP based on one of our ones stored in %LOCALAPPDATA%VisualGDBEmbeddedBSPs. The information is stored in XML files that could be easily edited.

Let us know if you need more details.

[support]

Hi,

It looks like VisualKernel fails to detect the port used by your VMWare stub. Which VMWare version are you using? If it’s an old one, it may have bugs related to the VM control API that VisualKernel is relying on.
Does VisualKernel show the “suspending VM/configuring VM/resuming VM” window?
Does your VMX file contain the following lines? (VisualKernel should add them if they are missing)

debugStub.listen.guest32 = 1
debugStub.listen.guest32.remote = "TRUE"
debugStub.hideBreakpoints = "FALSE"

If not, please try adding them manually and suspending/resuming the VM.

Does your vmware.log file contain lines similar to the following?

2014-04-06T12:15:45.346-07:00| vmx| W110: VMware Workstation is listening for debug connection on port 8832.
2014-04-06T12:15:45.346-07:00| vmx| W110:     target remote localhost:8832

If not, please send us your vmware.log file.

[support]

Hi,

Based on your log it looks like you are out of free space on your Linux machine. Note that the kernel sources and symbols need several gigabytes of space. Could you please try freeing up some space (e.g. adding another virtual disk and mounting /usr/src there)? Does it solve the problem? You can check your free space on Linux using the ‘df -h’ command.

[Author]

Posts