Shared library has no symbol table info when debugging with gdb and gdbserver

[Coleman]

I am cross compiling a native android shared library using meson and dynamically loading it using dlopen. However when remotely debuging my app with gdb there is no symbol table info for my shared library even though I am compiling with debug symbols (-g). Does anyone have any suggestions for how to fix this? Am I missing a compiler flag maybe?

[Alex Cohn]

On Wednesday, July 31, 2019 at 8:35:01 PM UTC+3, Coleman wrote:

I am cross compiling a native android shared library using meson and dynamically loading it using dlopen. However when remotely debuging my app with gdb there is no symbol table info for my shared library even though I am compiling with debug symbols (-g). Does anyone have any suggestions for how to fix this? Am I missing a compiler flag maybe?

Just as a lifehack, while debugging, try to load the library from Java (System.LoadLibrary()). Your dlopen will now be a (almost) NOP, but the chances to find the symbol table will be higher.

Sincerely,

Alex

 

[Coleman]

On Wednesday, July 31, 2019 at 11:35:01 AM UTC-6, Coleman wrote:

I am cross compiling a native android shared library using meson and dynamically loading it using dlopen. However when remotely debuging my app with gdb there is no symbol table info for my shared library even though I am compiling with debug symbols (-g). Does anyone have any suggestions for how to fix this? Am I missing a compiler flag maybe?

Just as a note if I compile a test program (pure native) using my shared library and execute it using gdbserver it loads all of the debug symbols correctly.

[Coleman]

Thanks for the advice. I tried adding System.loadLibrary to my Java code and now when attaching the debugger to the process it loads my library right away. However gdb now explicitly says there are no debugging symbols found for my library. Is this an issue with the clang compiler included in the ndk not outputting gcc compatible debug symbols? I don't know what else it could be. Trying to get backtraces when my app segfaults also seem to be corrupt (once the call stack gets to a function in my library it continues infinitely with random offsets into the same function).

[Dan Albert]

How are you invoking gdb? How are you building? What's the backtrace for the crash?

--
You received this message because you are subscribed to the Google Groups "android-ndk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to android-ndk...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/android-ndk/7e7cbf7e-3c91-48c2-b2f8-f46e55a8fb61%40googlegroups.com.

[Coleman]

I am running gdb like this:

./gdbserver :5049 --attach pid

and interacting with the server using a custom configured gdb binary (x86_64-linux build and aarch64-linux-android host).

My compile commands as generated my meson can be found here: https://pastebin.com/EzKZHMu0

As for the backtrace, my application is currently not crashing (fixed all of those bugs) however when it does or I run the backtrace command gdb complains about the previous stack frame being inner to this frame.

On Thursday,

To unsubscribe from this group and stop receiving emails from it, send an email to andro...@googlegroups.com.