0

I'm trying to debug a native built (NDK) executable test (+shared library) using adb shell, gdbserver on one side and the ndk's gdb on the other side.

I copied the executable and .so to the device and executed in adb shell:

$ gdbserver :5039 ./my_test my_args
Process ./my_test created; pid = 11131
Listening on port 5039

On the host I run gdb on the same my_test executable:

$ $NDK/toolchains/arm-linux-androideabi-4.8/prebuilt/linux-x86_64/bin/arm-linux-androideabi-gdb ./my_test

And put a breakpoint in main():

Reading symbols from /.../my_test...done.
(gdb) target remote :5039
Remote debugging using :5039
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().
0xb6f71a60 in ?? ()
(gdb) b main
Cannot access memory at address 0x0
warning: (Internal error: pc 0xa468 in read in psymtab, but not in symtab.)

warning: (Internal error: pc 0xa468 in read in psymtab, but not in symtab.)

warning: (Internal error: pc 0xa468 in read in psymtab, but not in symtab.)

warning: (Internal error: pc 0xa46c in read in psymtab, but not in symtab.)

warning: (Internal error: pc 0xa468 in read in psymtab, but not in symtab.)

...

When hooked to eclipse as remote debug the 'next statement' jumps to different places in the code when I attempt to step-by-step the code. This is the same thing that I see when I do a series of 'next' command in gdb.

gdbserver version on the device is 7.6.

Any ideas?

Update:

After building gdb 7.6.2 and using it instead of the gdb 7.3.1-gg which comes with the NDK release I have (r9d 64-bit), those warning messages of Internal error are gone.

What's left is the lack of sync between the code and debugging. I built the code with NDK_DEBUG=1 and copied the executable and .so from .obj dir to the device, but still when I do 'step-by-step' debug from gdb+gdbserver the program flow as seen from gdb doesn't make any sense.

miluz
  • 1,353
  • 3
  • 14
  • 22
  • You might try pushing your ndk's gdb and using that. As quick hack, any chance you could rename (or wrap) you main function to make it jni-compatible and have an empty java app which creates a thread and calls your native code in that, letting you use the normal ndk debug procedure? You could also try doing a normal ndk debug session on a sample app while watching to see exactly what is happening - gdb options and commands, etc. Another option that is often efficient is to simply build your code for the dev machine and debug it there. – Chris Stratton Aug 27 '14 at 14:43

1 Answers1

1

OK, the issue is resolved. Now the program flow as seen from gdb looks as expected.

These are the two things that were done and made it work:

  1. Build a newer version of gdb. Instead of the 7.3.1 which came with the NDK release (version r9d), I downloaded and built gdb with --target=arm-linux-gnueabi and used it.

  2. Previously I specified -g in APP_CPPFLAGS inside Application.mk. This time, I specified -ggdb -O0.

miluz
  • 1,353
  • 3
  • 14
  • 22