NDK R11c gdb debugging issue on Android

[LXS5461]

Recently upgraded from NDK R10e to R11c. I noticed that toolchain specific windows gdb.exe has been removed e.g., toolchains\arm-linux-androideabi-4.8\prebuilt\windows\bin\arm-linux-androideabi-gdb.exe. These gdb's were configured to be target specific. This was helpful to debug application deployed on android. I am not sure why its removed with the latest NDK version? I noticed a gdb.exe in android-ndk-r11c\prebuilt\windows\bin\gdb.exe. When I try to use it, I dont see it hit any breakpoints. 

1. Why has R11 removed the the target specific gdb.exe like arm-linux-androideabi-gdb.exe ?

2. Is "gdb.exe" <NDK>/prebuilt supposed to replace the functionality? If so, how can we make it work for different target types like arm-linux-android, aarch64-elf-linux. etc ?

Any help is appreciated in this regard?

Thanks,

[Dan Albert]

1: Because there's no point in shipping 6 GDBs when we can ship a single multiarch GDB.

2: Yes. Use ndk-gdb. Idk if there's any difference in how you have to use it directly compared to the per-arch GDB, but ndk-gdb will do the work for you.

--
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 post to this group, send email to andro...@googlegroups.com.
Visit this group at https://groups.google.com/group/android-ndk.
To view this discussion on the web visit https://groups.google.com/d/msgid/android-ndk/1d4851fe-5a78-4149-b947-0bc1bced88b6%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[LXS5461]

Thanks Dan.

I primarily use the gdb to debug pure native code (c++) deployed to android (no JAVA code). E.g., like debugging the drivers installed on the device. Earlier, by starting the target specific gdb session from the NDK, we would attach to the process on device and debug the native code. 

ndk-gdb expects AndroidManifest.xml file to be present before it can start the gdb session, which is not available in my case for  native libs.

I am not sure how I can configure the ndk-gdb to fit my usecase. Any insight here can be helpful.

Thanks,

[Dan Albert]

I thought ndk-gdb could be used to run an arbitrary executable (it certainly shares a fair amount of code with a tool that does), but I'm actually not all that familiar with ndk-gdb myself. +jmgao can probably help.

To view this discussion on the web visit https://groups.google.com/d/msgid/android-ndk/c4c7c9b1-5f5d-42c3-8fc2-d88340280f52%40googlegroups.com.

[Josh Gao]

[reposting, mailer didn't like that I wasn't in the group before emailing]

On Tue, Apr 26, 2016 at 9:58 AM, Dan Albert wrote:
> I thought ndk-gdb could be used to run an arbitrary executable (it certainly shares a fair amount of code with a tool that does), but I'm actually not all that familiar with ndk-gdb myself. +jmgao can probably help.

It can't right now, but I've been thinking of unifying gdbclient.py and ndk-gdb.py for a while. It's probably not going to happen any time soon, though.

 
On Tue, Apr 26, 2016 at 8:52 AM, LXS5461 wrote:
> 2. Is "gdb.exe" <NDK>/prebuilt supposed to replace the functionality? If so, how can we make it work for different target types like arm-linux-android, aarch64-elf-linux. etc ?

The gdb.exe we ship now is compiled with support for all of our architectures. gdbserver knows what target type it's built for, and will forward the information to gdb. However, there's an upstream bug with the r11c gdb and arm/aarch64 targets, that causes gdbserver to not mention that it's targeting linux. If you're running gdb on windows or mac, you'll need to explicitly use `set osabi GNU/Linux` before connecting. (There's a workaround in place in r12 for both gdb and the gdbservers; either one should fix the problem.)

[LXS5461]

Thanks Josh. 

Yes, I am running gdb on windows machine and connecting to the remote android target. (arm/aarch64)

It got further with this fix, but I still seem to have issues. 

When I try to attach to the process on device, I see the following error message in the gdb output..

Reading /system/bin/linker from remote target...

&"warning: File transfers from remote targets can be slow. Use \"set sysroot\" to access files locally instead.\n"

&"Error while mapping shared library sections:\n"

&"Could not open `target:/system/bin/linker' as an executable file: Invalid argument\n"

If I use the target specific gdb from r10e, ( on the same target, same libs), the operation succeeds.

=library-loaded,id="/system/bin/linker",target-name="/system/bin/linker",host-name="<host-path>\linker",symbols-loaded="0",thread-group="i1"

I am not sure if I am missing anything here. Any suggestions?

Thanks!

[Josh Gao]

Which version of gdbserver are you running with each?

[LXS5461]

I had tried with gdbserver version 7.6. Is this not expected to work?

When I use gdbserver version 7.10, it says its able to load symbols, but I dont see it hit any breakpoints in my code. Address of all the breakpoint in "info breakpoints" is PENDING. 

"info shared" in gdb does not display the host path 

I see..

From                To                       Syms read       Shared Obj lib

0xXXX6XXXX  0xXXX7XXXX      Yes                 target:/system/lib/abc.so

instead of something like.. 

From                To                       Syms read       Shared Obj lib

0xXXX6XXXX  0xXXX7XXXX      Yes                 <hostpath>\obj\local\armeabi-v7a\abc.so

Please let me know if I can provide more info.

Thanks Josh! Appreciate your help.

[LXS5461]

Was able to resolve this issue by settings the hostpath as sysroot in gdb. (set sysroot). 

Thanks a lot Dan and Josh for your help!