[ket]

Hi,

Adding the -gdwarf-3 flag to LOCAL_C_FLAGS of all your modules in Android.mk should have solved the issue. Using the 4.8 toolchain from Android NDK and having debugging otherwise working but no variable values shown is the symptom for this issue. Are you certain that you rebuilt the solution after adding this flag?

You can also switch to using the 4.6 toolchain with the latest NDK. The toolchain version can be changed on the Makefile settings page in VisualGDB Project Properties.

Could you give an example of variable values you are trying to see (code example, at which line of code is execution paused and which variable values are you trying to see)? Only variables that have been initialized and are within the current execution scope can be seen by gdb.

[ket]

Hi,

Is your project code where you are trying to include pthread functions written in c++? If so, then you need extern “C” { } around your pthread include (and any other c library include) as follows:

extern "C" {
#include 

}

[ket]

Hi,

The Deploy step is not needed or used for VisualGDB projects, somehow VS has set this option for the project. Please go to Build->Configuration Manager and remove the check from Deploy for this project.

[ket]

Hi,

The SIGINT and SIGTRAP signals are supposed to happen when break all is used, that is how break all works for that platform.
For the first issue, please give us a full gdb log. You can enable diagnostic gdb logging on the GDB settings page of VisualGDB Project Properties. Then start debugging and replicate your scenario (set a breakpoint in main before starting debugging), stop debugging and give us the log file from your project directory.

[ket]

Hi,

VisualGDB uses the IntelliSense feature provided by Visual Studio. Only Visual Studio versions 2012 and 2013 have added gradual support for c++0x and c++11, the Visual Studio 2010’s IntelliSense is going to have issues understanding any c++0x/c++11 syntax.

If you are using our generated makefiles, then there is also no need to add IntelliSense directories separately, VisualGDB will look at the include directories and set the IntelliSense directories automatically.

If you need further help with IntelliSense errors, please post a lists of them here.

[ket]

Hi,

The compiler does try to build your .s file as assembly code, so you should not need any additional flags.

In your Android.mk file, you are overriding the LOCAL_SRC_FILES to contain only the .s files and not the .cpp and .c files because you are using := not +=. If you intend to build both assembly and c/c++ files for your app, then the second LOCAL_SRC_FILES definition should use += to append files instead.

As for the errors in your assembly file bac.s, they seem to be pointing to actual problems with this file. You are using unknown instructions and unknown syntax in this file. You should be using gcc ARM assembly syntax here for gcc to be able to compile this file not just ARM assembly syntax.

[ket]

Hi,

If you are using VisualGDB on a machine with no internet connection, then you can download the STM32 bsp from http://visualgdb.com/hwsupport/BSP/ and the arm toolchain from http://gnutoolchains.com/arm-eabi/ . The bsp should be installed in the embedded project wizard where usually the BSPs are downloaded for devices, but use the “Install a package from file” option there. The arm-eabi toolchain should be installed just from using the installer.

• This reply was modified 9 years, 8 months ago by support.

[ket]

Hi,

The GDB settings option in VisualGDB Project Properties is called “Use relative source file paths instead of querying full path lists”.

[ket]

Hi,

Please add to CFLAGS on the Makefile settings page of VisualGDB Project Properties the following flag:

-std=c99

If you are using your own makefile, then add it to the makefile in an equivalent location so that the flag is passed to gcc.

[ket]

Hi,

1), 2) You may need additional flags or includes in the makefile. It is not clear what the exact issue here is, please post the build log from the Output window showing the errors and a screenshot of how you are calling the arm instructions.
3) Either of these toolchains is available for ARM and hence will compile fine for ARM. If you wish to compile for ARM only, then change the ABI of the application to armeabi and/or armeabi-v7a. This way the app will not be built for other platforms.

[ket]

Hi,

You can also adjust the file transfer settings on the Project Properties page in VisualGDB Project Properties. If you change the local directory there, then please change the makefile name on the Makefile settings page to be a relative path relative to that local directory.
Another option would be to have that header file in one of the project directories, if the other project is dependent on the project with the header file, then both projects will be transferred on build.
However, for a single file it is probably easier to just use a custom build step.

[ket]

Hi,

If the library is available locally on your development machine and you have referenced the library (the library name and potentially the library directory as well) on the Makefile settings page of VisualGDB Project Properties, then that should be all you need to do.
If you have done the previous, then please check if you using a c library in c++ code without having extern “C” {} around the include header statements of the library.

[ket]

Hi,

Yes, you should first install the library on the Raspberry Pi itself and then resynchronize the sysroot. You can resynchronize the sysroot on the Makefile settings page in VisualGDB Project Properties.

Our wiringPi tutorial goes through the steps of using libraries with the Raspberry Pi cross-toolchain, you can use that as reference:
http://visualgdb.com/tutorials/raspberry/wiringPi/

[ket]

Hi,

VisualGDB itself does not use .pdb files and you do not need one either, this is just a standard message from Visual Studio meaning the debug symbols for libc are not available.

You are probably getting this message because you are stepping into libc functions. However as libc is a system library it is not built with debug symbols as system libraries are usually optimized release versions. If you wish to step into libc, then you need a debug build of libc that has the debug information available. If you wish to do so, then you may need to build such a libc yourself and switch it out with the libc that comes with your Linux.

As for using a modified Raspberry PI toolchain, have you resynchronized the sysroot of the toolchain to make it a bit more compatible? You can resynchronize the sysroot automatically on the Makefile settings page in VisualGDB Project Properties or manually if you are using your own makefile. This however will not affect the above issue, the same holds for most system libraries on Linux systems. Feel free to post more information on the exceptions you get and the system you are really targeting, so we can help you more with compatibility issues.

[ket]

Hi,

The values are not shown with the 4.8 toolchain due to a known issue with the toolchain. The gcc and gdb versions of the Android NDK 4.8 toolchain are too far apart and default to different debug symbol versions. Please add -gdwarf-3 to LOCAL_C_FLAGS in Android.mk. This flag forces gcc to produce debug info in an older format compatible with the older gdb and should fix the issue. Please rebuild your project with this flag before trying debugging again with the 4.8 toolchain.

As for the breakpoints not being hit with clang 3.3, we would need to see the full gdb log to diagnose that issue. Please enable gdb logging on the GDB settings page in VisualGDB Project Properties. Then start debugging, replicate you scenario (make sure some breakpoints were set), stop debugging and give us the log from your project directory.

Please note, that if you are debugging code that is executed very early in the app startup, then try enabling the Android->Debug Options->Debug App Startup option.

[Author]

Posts