- This topic has 6 replies, 2 voices, and was last updated 12 years ago by
.
-
Posts
-
I have a native android app that builds and runs ok (with bugs of course!) so I’m trying out this tool.
Everything seemed to be pretty happy; the New Android Project wizard read in my existing Android.mk files (plural, I have many in a subdir hierarchy) and created a nice project for me, that also builds correctly.
When I hit run though, my breakpoints won’t set. Here is what the GDB session outputs. See below (way, way below) for a snippet of what my Android.mk files look like.-break-insert -f r:/Projects/VA128//jni/arch_android.cpp:146 ^done,bkpt={number="5",type="breakpoint",disp="keep",enabled="y",addr="",pending="r:/Projects/VA128//jni/arch_android.cpp:146",times="0",original-location="r:/Projects/VA128//jni/arch_android.cpp:146"}
VisualGDB for Android is trying to repair your breakpoints...
info shared
From To Syms Read Shared Object Library
0x00002a00 0x00022d98 Yes C:/Users/Joel/AppData/Local/VisualGDB/AndroidBinaryCache/emulator-Intel_Android16/linker
0xb8016ed0 0xb807d844 Yes C:/Users/Joel/AppData/Local/VisualGDB/AndroidBinaryCache/emulator-Intel_Android16/libc.so
No libstdc++.so
No libm.so
No liblog.so
No libcutils.so
No libgccdemangle.so
No libcorkscrew.so
No libz.so
No libutils.so
No libbinder.so
No libemoji.so
No libjpeg.so
No libexpat.so
No libskia.so
No libandroidfw.so
No libstlport.so
No libnativehelper.so
No libnetutils.so
No libhardware.so
No libui.so
No libwpa_client.so
No libhardware_legacy.so
No libGLES_trace.so
No libEGL.so
No libGLESv2.so
No libgui.so
No libcamera_client.so
No libgabi++.so
No libicuuc.so
No libicui18n.so
No libsqlite.so
No libdvm.so
No libGLESv1_CM.so
No libETC1.so
No libsonivox.so
No libcrypto.so
No libssl.so
No libstagefright_foundation.so
No libspeexresampler.so
No libaudioutils.so
No libmedia_native.so
No libmedia.so
No libusbhost.so
No libharfbuzz.so
No libhwui.so
No libandroid_runtime.so
No libjavacore.so
No libdrmframework.so
No libstagefright_omx.so
No libstagefright_yuv.so
No libvorbisidec.so
No libchromium_net.so
No libstagefright_enc_common.so
No libstagefright_avc_common.so
No libstagefright.so
No libmtp.so
No libexif.so
No libstagefright_amrnb_common.so
No libmedia_jni.so
No libbcinfo.so
No libbcc.so
No libRS.so
No librs_jni.so
No libandroid.so
No libwebcore.so
0xaac777c0 0xaae7365c Yes R:/Projects/VA128/obj/local/x86/libVA128Native.so
No lib_renderControl_enc.so
No libGLESv2_enc.so
No libGLESv1_enc.so
No libOpenglSystemCommon.so
No libEGL_emulation.so
No libGLESv1_CM_emulation.so
No libGLESv2_emulation.so
No gralloc.goldfish.so
OK
-exec-continue
^running
*running,thread-id="all"To get around the ridiculously non-operational call all-subdir-makefiles script, I use a format like this in my Android.mk files:
LOCAL_PATH := $(call my-dir) MY_SAVED_LOCAL_PATH := $(LOCAL_PATH) LOCAL_MODULE := VA128Native LOCAL_SRC_FILES := va128.c native_app_glue_entry.cpp arch_android.cpp LOCAL_C_INCLUDES := $(LOCAL_PATH)/v24 LOCAL_C_INCLUDES := $(LOCAL_PATH)/core LOCAL_WHOLE_STATIC_LIBRARIES := android_native_app_glue myOtherStaticLibsThatAreNumerous include $(BUILD_SHARED_LIBRARY) LOCAL_PATH := $(MY_SAVED_LOCAL_PATH) include $(LOCAL_PATH)/v24/Android.mk LOCAL_PATH := $(MY_SAVED_LOCAL_PATH) include $(LOCAL_PATH)/v24/arch/android/Android.mk # Lots and lots moreI wonder if the problem is in the ‘//’ that somehow got generated as part of the path? Or, maybe it’s something else?
Hi,
Please run the “info sources” command as described here.
The command will list all source files known by GDB and will probably answer why r:/Projects/VA128//jni/arch_android.cpp is not accepted.
Feel free to post the “info sources” output here.Thank you for your reply. That page was helpful for me understanding what was going on, at least partially. I had paths of the form:
r:/Projects/VA128//jni/arch_android.cppin my “info sources” but paths of the form
r:ProjectsVA128/jni/arch_android.cppwere expected by my .so file. From the helpful page you sent me:
Note that GDB requires the file path to be EXACTLY the same as reported by “info sources”, including double slash before “jni”.
A clean build using VisualGDB’s built-in make commands resolved that problem. Nice!
Unfortunately, it’s still not working. But now, I get this:^done,bkpt={number="2",type="breakpoint",disp="keep",enabled="y",addr="",pending="r:/Projects/VA128//jni/arch_android.cpp:118",times="0",original-location="r:/Projects/VA128//jni/arch_android.cpp:118"}
-var-create --frame 0 --thread 1 - * "pGL"
-var-create: unable to create variable objectNot quite sure what to do next 🙂
That is very strange. Is the library actually loaded at the time you set the breakpoint? Could you please run the “info sources” and “info shared” commands just after you set the breakpoint and post the entire log containing all 3 commands here?
No problem. It’s too big to include here (by almost double) so I’ve attached it as a separate file.
[attachment=1:187uuw55]VisualGDB info.zip[/attachment:187uuw55]
Hope it’s helpful! 🙂
Edit: Hmm, could it be the lower-case ‘r’ drive letter vs. the upper-case ‘R’ drive letter?? Where did that lower-case one come from? 🙂
Edit 2: Here’s Visual GDB’s startup output in case it’s helpful: [attachment=0:187uuw55]VisualGDB startup.zip[/attachment:187uuw55]
Thank you for the log files!
It looks like there’s a bug in gdb 6.x shipped with the latest NDK that it refuses to take fully-qualified file paths on Windows. On ARM targets this is fixed by using prebuilt GDB 7.x that is provided with VisualGDB.
We have added a workaround to the upcoming VisualGDB 2.8 to use file-name-only syntax as a last resort if GDB refuses to accept all other file name variations.The only workaround with the current version is to issue the breakpoint commands with file-name-only syntax manually (e.g. -break-insert -f arch_android.cpp:116).
Alternatively you could use an ARM target until we release VisualGDB 2.8.
- You must be logged in to reply to this topic.