Forum Replies Created
-
Posts
-
Hi,
TARGET_CXX is a variable value VisualGDB tries to get from gcc to test whether a trivial program will build, it is not something that you should set. All the toolchain test failure means is that the project may not build because there are some issues such as missing settings. Please try to ignore the toolchain test error and create the project anyway. When you build the actual project the build output provided should be more helpful in showing the actual issue.
A common cause for this error is if you are importing a project that needs the NDK_MODULE_PATH variable defined. There is no place to specify it in the wizard, but it can be defined once the project is made as an additional argument to ndk-build on the Build settings page in VisualGDB Project Properties.
Hi,
The crypto.so library could be running some initialization code when it is loaded even if you are not calling any functions from it. It is common for libraries to test instruction set availabilities when initializing.
By default gdb will stop at any signals such as SIGILL. When you are just running the program the SIGILL signal happens as well, but the library handles it silently and remembers that this instruction is not available.HI,
Please check inside the Makefile in the project directory if there are any obvious issues with targets or recipes like non-existing path names.
You can also run the make command with the -d argument to get a more thorough output from make. For this add the -d flag to make command arguments on the qmake project settings page in VisualGDB Project Properties. Then examine the log for any errors.
Hi,
You can view CPU registers in the Registers window (can be shown from Debug->Windows->Registers during debugging) in Visual Studio. Then right-click on the Registers window and select which register groups to show.
For some embedded devices we show a special peripheral registers window, otherwise enter the peripheral register name into the Watch window to see its value.Hi,
Firstly, please try deleting the folder “C:/Users/Steve/AppData/Local/VisualGDB/AndroidBinaryCache/HT0B2RX05487” with all its contents and then try debugging again.
If this does not work, then please remove all handle signal commands from the startup page. Please enable gdb logging on the GDB settings page and start debugging. Let the SIGILL happen, make a screenshot like you made before (showing the disassembly and call stack) and stop debugging. Then please give us the gdb log from your project directory and the screenshot.
Hi,
Happy Holidays to you as well!
The cross-compilation issue was fixed in VisualGDB version 4.1r8, so just update VisualGDB to the latest version and repatch the cross-compilation Qt to fix that (delete the Qt subfolder and the sysroot contents from the Raspberry Pi toolchain location and make another new Raspberry Pi cross-toolchain project).
Probably what is missing from your project is the listing of the resource file. Look into our project example, in the file RaspberryQt.pro there is the following line:
RESOURCES = basicgraphicslayouts.qrcYour project’s pro file should contain a similar line. Please note that currently VisualGDB does not update the resources list automatically, so you need to add this line manually.
Hi,
The generated Makefile should contain a call to rcc.exe, so make should also call rcc.exe automatically.
If you build your project with VisualGDB, in the Output window does the build output contain a call to rcc.exe? If it does not, does the generated Makefile in the project directory contain a call to rcc.exe ?
Hi,
The Qt4 packages need to be installed on the BBB as those Qt libraries will be used for building. QtCrossTool does the same as the wizard.
Setting up Qt on BBB takes some initial manual steps due to BBB running Angstrom linux. Please follow one of the tutorial on setting up Qt on BBB, all the necessary steps are described there (http://visualgdb.com/tutorials/beaglebone/qt-embedded/ or http://visualgdb.com/tutorials/beaglebone/qt-x11/).
Hi,
A similar issue was recently reported. VisualGDB version 4.1r8 included a fix that could affect building when qrc files are present, but we were unable to replicate the issue of images not showing up.
We have attached the project we used to test images and qrc files, it is based on a Qt example project. The Debug configuration builds on the Raspberry Pi, the Debug2 configuration uses the cross-compiler. Feel free to try it out to see if images show up for you. You will at least need to change the SSH connection setting to Raspberry Pi in VisualGDB Project Properties to use the project.
Please let us know if the project works for you. If it does work, then it would be helpful if you could tell what is different between the non-working and working projects i.e. what makes the images not show up.
Hi,
Does your library use NEON instructions and the device does not support them? Sometimes libraries test the CPU instruction set when loaded and will determine which instruction set to use based on the SIGILL signal.
Have you tried ignoring the signal and continuing?
GDB will by default stop at all such signals. You can try adding the following to the GDB startup command page in VisualGDB Project Properties:
handle SIGILL nostop passYou can find more information on handling signals in GDB here:
https://sourceware.org/gdb/onlinedocs/gdb/Signals.html
Please note that an issue was recently fixed with the GDB startup command page in VisualGDB, so please make sure you are using at least version 4.1.r8 before using GDB startup.You can also try understanding what gives the SIGILL signal, when the signal happens instead of continuing break and look at the call stack and disassembly to understand what function gives it.
Hi,
Where the binary of your build is located depends on the project type. If your project is a normal Linux project built on the BeagleBone then the binary is in the build directory on the device, you can see the file transfer path on the project settings page in VisualGDB Project Properties (by default a subdirectory of /tmp/VisualGDB). If you are building the Linux project using a cross-compiler, then the binary is in the project directory on the Windows machine, before debugging the binary is deployed to /tmp. If your project is an Android project producing an apk file, then this also can be found in the project directory on the Windows machine, during deployment it is installed as all other apps on the Android device. Usually VisualGDB does not rename the binaries, only library project outputs and Android apk files have the necessary prefixes and suffixes appended.
The best way to transfer files between the device and the Windows machine depends on the use case. Source files for Linux projects are transferred automatically, if anything else is needed for routine transferring then adding transfer commands to Custom build steps, Custom debug steps and Custom shortcuts in VisualGDB Project Properties is most convenient. If SSH is not possible due to using Android, then make these commands use “adb pull” or “adb push” instead. For one-off transfers you can open an SSH console to the device from Tools->SSH Host Manager and use the SCP menu there.
Hi,
VisualGDB uses the machine interface when issuing commands to gdb. Make sure that you are starting gdb with the argument “–interpreter mi”.
You can see the full gdb log also from the GDB Session window, just set the filter above to “All GDB interaction”, the content of the log is usually filtered because it provides a lot of output.Hi,
If it works the first time but not after, then check whether any of your manual file changes were automatically overwritten by ANT or VisualGDB.
Hi,
We have looked further into this. To enable debugging also in the dependent library, change the project’s (not the library’s) Android.mk file, the shared-prebuilt’s LOCAL_SRC_FILES should not contain the libs subfolder, but obj/local as in the case of static-prebuilt. Then the symbols will be properly loaded.
