I'm trying to debug an NDK project on Windows using Eclipse (Kepler), but GDB won't find the symbols for the .so file, because the direction of the slashes in the search path are incorrect. Using NDK r9 and SDK 22.2.1, when I try and run the application, GDB shows:
warning: Could not load shared library symbols for 64 libraries, e.g. /system/bin/linker.
Use the "info sharedlibrary" command to see the complete listing.
Do you need "set solib-search-path" or "set sysroot"? warning: Unable to find dynamic linker breakpoint function.
GDB will retry eventurally. Meanwhile, it is likely that GDB is unable to debug shared library initializers or resolve pending breakpoints after dlopen().
No symbol table is loaded. Use the "file" command.
No symbol table is loaded. Use the "file" command.
No symbol table is loaded. Use the "file" command.
The "No symbol table is loaded..." lines appear once for each breakpoint set in my library. The problem seems to be that GDB isn't finding the unstripped .so file, as the search path contains backslashes instead of forward slashes. If I pause the program and execute the following GDB commands, this is the output I get:
show solib-search-path
The search path for loading non-absolute shared library symbol files is C:\\Users\\Username\\Projects\\Project\\Android/obj/local/armeabi-v7a/.
info shared
From To Syms Read Shared Object Library
0x4003fff0 0x4006db40 Yes C:/Users/Username/Projects/Project/Android/obj/local/armeabi-v7a/libc.so
0x5bda8598 0x5bf5aa50 No C:/Users/Username/Projects/Project/Android/obj/local/armeabi-v7a/libProject.so
If I then update the solib-search-path to use forward slashes, I get this:
set solib-search-path C:/Users/Username/Projects/Project/Android/obj/local/armeabi-v7a/
warning: Could not load shared library symbols for 74 libraries, e.g. /system/bin/linker.
Use the "info sharedlibrary" command to see the complete listing.
Do you need "set solib-search-path" or "set sysroot"?
warning: Unable to find dynamic linker breakpoint function.
GDB will retry eventurally. Meanwhile, it is likely
that GDB is unable to debug shared library initializers
or resolve pending breakpoints after dlopen().
info shared
From To Syms Read Shared Object Library
0x4003fff0 0x4006db40 Yes C:/Users/Username/Projects/Project/Android/obj/local/armeabi-v7a/libc.so
0x5bda8598 0x5bf5aa50 Yes C:/Users/Username/Projects/Project/Android/obj/local/armeabi-v7a/libProject.so
After which point GDB will successfully hit breakpoints in the native code. The gdb.setup file in the libs\armeabi-v7a folder has the line:
set solib-search-path ./obj/local/armeabi-v7a
But I'm not sure where this path gets changed into an absolute path. I'm guessing it's at that point that GDB uses the path with backslashes instead of forward slashes, but I'm not sure where that happens. I did try modifying the Android NDK build scripts that create the gdb.setup file, and even tried putting in a different path, but the output from show solib-search-path was just the same, so I'm not even sure GDB is using that search path. Has anyone come across this problem before, or does anyone know how I can get GDB to start up with the correct search path when I run from Eclipse?
I think this may have just been GDB not loading the symbols until a later time. I did have a delay before loading the project's .so, to allow GDB time to connect. I moved the delay until after the call to loadLibrary, and it seems to be picking up the symbols fine now.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With