Forum Replies Created
-
Posts
-
Hi,
These commands are not logged anywhere. What exactly are you trying to do? We may be able to tell you another way to accomplish this with VisualGDB.
Hi,
It looks like this issue: https://code.google.com/p/android/issues/detail?id=60496
Some of the discussions on the issue are also here: https://plus.google.com/+AndroidDevelopers/posts/hNZNjqKLpny
Try the workarounds discussed there.Hi,
Based on the fact that some variables even from the same file have readable values, it is highly likely that the compiler has somehow optimized the iWantToReadYou variable out. Based on the build log however, there are no unusual flags passed to g++. There are the additional flags that cocos2dx needs, but none of them should affect optimization. It could be a compiler bug to still perform some optimization.
If you wish to look further into it, look into the so file using objdump. Find the correct objdump.exe for your toolchain in your Android NDK installation directory and call objdump from cmd as follows:
--dwarf lib > 0 Then open the 0 file with a text editor and search for iWantToReadYou.
Hi,
It looks like the pre-debug steps are executed fine. The problem here is that the LD_LIBRARY_PATH variable should be specified as part of gdb’s environment, setting the variable in a separate command will not pass it to gdb as it is executed in a different channel.
To set the LD_LIBRARY_PATH variable for gdb, please go to Debug settings in VisualGDB Project Properties. There switch to using a custom GDB executable, then press on Customize and add the LD_LIBRARY_PATH variable definition to the environment variables there. Note that this will not work if you are using a gdbserver (building and debugging on a different machine). We will add an option to specify the debug environment in the case of gdbservers in the next version of VisualGDB.
Hi,
Yes, we can also replicate the issue. We are still looking into it deeper.
You could switch to using the static version of the library, then launching and debugging will work as there will be no additional library to load. The app will start without crashing using the shared version of the library if you add a System.loadLibrary(“AndroidLibrary1-shared”) call into the app’s Java code. This call should be before the System.loadLibrary(“AndroidProject20”) call. In our tests this was not enough to enable setting breakpoints in the AndroidLibrary1-shared library’s code, we are still looking into enabling that. If you could let us know which exact versions of Android NDK, Android SDK Tools, Android SDK Build-tools (listed in the Android SDK Manager), ANT and Java JDK you are using, it could help us narrow down the issue more. Also knowing the app’s target Android platform and the Android device’s platform would be helpful.Hi,
Please check in the Output window for any errors for the pre-debug steps, change the filter to show output from VisualGDB Launcher.
Hi,
The library is deployed inside the apk file and it is put there during build. Check inside the apk file for the library with any zip program, it should be in the directory matching your abi. If it is not there try rebuilding the solution and watch for any errors or warnings, then check the apk again. The library is supposed to be first copied into the libs folder and then into the apk in bin.
Hi,
Based on the log, the symbols are loaded. The early errors in the log about symbols not being loaded are before gdb even connects to the Android device and loads the symbols. Based on the log you should also be able to see the call stack, threads and step through code. The gdb does reply that it cannot create the variable iWantToReadYou, that happens when it does not know of any variable with that name.
It could be that the code was optimized and that iWantToReadYou was optimized out. As clang is a completely different compiler from gcc, it does compilation and optimization differently. Try adding V=1 to the ndk-build arguments and post the gcc command line from the build output in the Output window here. Also is iWantToReadYou the only variable not shown i.e. are there any variables shown in the Locals and Autos windows?
Hi,
Look in the LogCat for any errors. When the app is killed it is usually Android itself killing it due to some problems related to the Java code or app setup.
You can display the LogCat window without a current debug session from Debug->Windows->Android LogCat.
Hi,
The build log is in the Output window.
If you fill in your company details on the order including your EU VAT ID, you will not be charged VAT.
Hi,
VisualGDB could theoretically work with Qt5, but we are currently not officially supporting it as there is no current way to just apt get install Qt5 on Raspberry Pi and Beaglebone. The only way to use Qt5 on Raspberry Pi and Beaglebone is to compile it from sources yourself.
The compiler knows the sysroot directory, all the paths used should be absolute. Adding it to PATH should not be needed. Please post the build log and copy the error messages here.
Hi,
Not every part of code you can hover over is a genuine variable. We poll the gdb always to ask whether it is a variable and then show the variable’s information if applicable. Please try the Autos and Locals windows to see all the current variables listed or enter them to the Watch window.
If genuine variables are still not shown, then please give us a full GDB log showing all the GDB interaction. For this enable diagnostic GDB logging on the GDB settings page in VisualGDB Project Properties. Then start debugging and replicate your scenario. Finally stop debugging and send us the resulting log file from your project directory.
Hi,
That line should normally not give any issues.
Do you have any other toolchains on the PATH that include test or mkdir? Which part of “test -d Debug/ || mkdir Debug/ ” gives problems, is it “test -d Debug/” or “mkdir Debug/”? What is the output of each of them and the entire line together when executed from cmd?
Hi,
Both armv6 and armv7 support floating point numbers, but do it somewhat differently. armv6 uses VFPv2 and Thumb, armv7 VFPv3 and Thumb2. armv6 has hardware support for double precision floating point arithmetic, armv7 has legacy support for double precision arithmetic but fast single precision arithmetic due to the NEON unit.
Hi,
We have released a tutorial on using Qt on Android with VisualGDB. You can find it here.
