Native gdb can't know multithreads of Android processes

Bug #926472 reported by Barry Song
10
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Linaro GDB
Won't Fix
Wishlist
Thiago Jung Bauermann

Bug Description

I compiled a native gdb using linaro 2011.10 by “./configure --host=arm-none-linux-gnueabi --target=arm-none-linux-gnueabi”, and
the gdb runs on arm target boards directly.
# gdb
GNU gdb (Linaro GDB) 7.3-2011.10
Copyright (C) 2011 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "arm-none-linux-gnueabi".
For bug reporting instructions, please see:
<http://bugs.launchpad.net/gdb-linaro/>.
(gdb)

I can use it to debug native programs on target boards directly. For
example, attach process, set breakpoints, check registers and memory.
One issue is I can't see multi-threads, for example:

PID 646 is system_server by ps
"646 1000 159m S system_server"

Then I use gdb to attach it:

# gdb attach 646
(gdb) info threads
 Id Target Id Frame
* 1 process 646 "system_server" __ioctl ()
   at bionic/libc/arch-arm/syscalls/__ioctl.S:15

as you see, “info threads” only shows one thread but there are several
threads in system_server.

But if I compile a new program based on glibc and gnu libthread, I can
see multi-threads by the gdb.

different libthread names might be an issue for gdb to know multithreads. android has libthread_db.so but gnu has libthread_db.so.1. there are two ways to handle this issue:
1. ln -s /system/lib/libthread_db.so /system/lib/libthread_db.so.1
2. patching gdb
i did have changed linaro-gdb 11.10 release by:

diff --git a/gdb/arm-linux-tdep.c b/gdb/arm-linux-tdep.c
index ca0bc30..486faf6 100644
--- a/gdb/arm-linux-tdep.c
+++ b/gdb/arm-linux-tdep.c
@@ -98,8 +98,8 @@ static const char arm_linux_thumb2_le_breakpoint[] =
{ 0xf0, 0xf7, 0x00, 0xa0 };
   buffer. This is also true for the SoftFPA model. However, for the FPA
   model the PC is at offset 21 in the buffer. */
 #define ARM_LINUX_JB_ELEMENT_SIZE INT_REGISTER_SIZE
-#define ARM_LINUX_JB_PC_FPA 21
-#define ARM_LINUX_JB_PC_EABI 9
+#define ARM_LINUX_JB_PC_FPA 24/*21*/
+#define ARM_LINUX_JB_PC_EABI 24/*9*/

 /*
   Dynamic Linking on ARM GNU/Linux
diff --git a/gdb/gdb_thread_db.h b/gdb/gdb_thread_db.h
index 957ed2c..51ed4fa 100644
--- a/gdb/gdb_thread_db.h
+++ b/gdb/gdb_thread_db.h
@@ -2,7 +2,7 @@
 #include <thread_db.h>

 #ifndef LIBTHREAD_DB_SO
-#define LIBTHREAD_DB_SO "libthread_db.so.1"
+#define LIBTHREAD_DB_SO "libthread_db.so"
 #endif

 #ifndef LIBTHREAD_DB_SEARCH_PATH

But both 1 and 2 can't simply fix the problem. if we compile gdb
statically by "make LDFLAGS=-static", it will finally come into a
crash:
# gdb attach 643
GNU gdb (Linaro GDB) 7.3-2011.10
Copyright (C) 2011 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
this is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "arm-none-linux-gnueabi".
For bug reporting instructions, please see:
<http://bugs.launchpad.net/gdb-linaro/>...
attach: No such file or directory.
Attaching to process 643
Reading symbols from /system/bin/app_process...done.
BFD: /system/bin/linker: warning: sh_link not set for section `.ARM.exidx'

warning: Could not load shared library symbols for 6 libraries, e.g.
gralloc.default.so.
Use the "info sharedlibrary" command to see the complete listing.
Do you need "set solib-search-path" or "set sysroot"?
Reading symbols from /system/bin/linker...(no debugging symbols found)...done.
Loaded symbols for /system/bin/linker
Reading symbols from /system/lib/libc.so...done.
Loaded symbols for /system/lib/libc.so
Reading symbols from /system/lib/libstdc++.so...(no debugging symbols
found)...done.
Loaded symbols for /system/lib/libstdc++.so
Reading symbols from /system/lib/libm.so...(no debugging symbols found)...done.
Loaded symbols for /system/lib/libm.so
...
__ioctl () at bionic/libc/arch-arm/syscalls/__ioctl.S:15
15 bionic/libc/arch-arm/syscalls/__ioctl.S: No such file or directory.
       in bionic/libc/arch-arm/syscalls/__ioctl.S
gdb: ../sysdeps/unix/sysv/linux/getpagesize.c:32: __getpagesize:
Assertion `_rtld_global_ro._dl_pagesize != 0' failed.
Aborted
#

then i simply hardcoded __getpagesize() to return 4096 and avoid the assert:

001d9b70 <__getpagesize>:
 1d9b70: f44f 5080 mov.w r0, #4096 ; 0x1000
 1d9b74: 4770 bx lr
 1d9b76: bf00 nop

this "fixed" Assertion `_rtld_global_ro._dl_pagesize != 0' , but it
still can't find multi-threads for android processes:
(gdb) info threads
 Id Target Id Frame
* 1 process 645 "system_server" __ioctl ()
   at bionic/libc/arch-arm/syscalls/__ioctl.S:15

(gdb) info threads
 Id Target Id Frame
* 1 process 938 "mediaserver" __ioctl ()
   at bionic/libc/arch-arm/syscalls/__ioctl.S:15

PS: now there is a platform/external/gdb.git tree in http://android.git.linaro.org/gitweb. i would suggest linaro make the gdb compilable with an Android.mk by arm-eabi-gcc just like other external components something like:
LOCAL_PATH := $(call my-dir)
include $(CLEAR_VARS)

LOCAL_MODULE_TAGS := eng

LOCAL_MODULE := gdb

LOCAL_SRC_FILES += \
      ... \

include $(BUILD_EXECUTABLE)

finally, i hope that will result in a native gdb running on boards and supporting multithreads. that is actually very useful to many users.

Revision history for this message
Thiago Jung Bauermann (thiago-bauermann) wrote :

Hello,

Sorry for taking this long to respond. It took me this long to wrap my head around Android and its version of GDB.

I tried to reproduce your native build of GDB but couldn't. From what I understand, you built a dynamically linked GDB using Linaro's toolchain and the arm-linux-gnueabi target. That produces a binary which is linked against glibc, which won't work on Android.

I was able to create a statically linked GDB though, but that's not very useful in this case because, like gcc warns, "Using 'dlopen' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking". Since Android doesn't even use glibc it can never work.

What I was able to do was build a dinamically linked gdbserver version 7.3 using Android's toolchain from the NDK and the arm-linux-androideabi target and modified to look for libthread_db.so instead of libthread_db.so.1 (just like you did). That worked when using GDB 7.3 on the host (you have to set solib-search-path to a copy of the device's /system/lib on the host) . It shows all threads using /system/lib/libthread_db.so.

Perhaps that is a suitable workaround for you at this moment.

I'm investigating adding Android support for Linaro GDB, and will also look into why Google ships a gdbserver statically linked with libthread_db if they have a working (at least on the surface) dynamic library.

Revision history for this message
Thiago Jung Bauermann (thiago-bauermann) wrote :

I'm interested in knowing how you built your native GDB binary.

I'll note though that we most likely won't support native Android debugging in Linaro GDB, just via gdbserver.

Is there a reason why you need to debug natively? Would a working Linaro gdbserver for Android be good enough for you?

I'll mark this bug as incomplete while you don't answer these questions, and also as a wishlist since native debugging won't be a priority for Linaro GDB.

Changed in gdb-linaro:
assignee: nobody → Thiago Jung Bauermann (thiago-bauermann)
importance: Undecided → Wishlist
status: New → Incomplete
Revision history for this message
Will Newton (will-newton) wrote :

No response in two years, so closing.

Changed in gdb-linaro:
status: Incomplete → Won't Fix
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.