Question

当我在android上尝试一些东西时，我遇到了一个有趣的问题。我在pthread_mutex_lock中定义了一个名为libx.so的函数，添加了一个测试应用程序，该应用程序按顺序与libx.so和libc.so链接：

arm-linux-androideabi-readelf -d ./libx-test.out:

Dynamic section at offset 0xebc contains 29 entries:
Tag        Type                         Name/Value
...
0x00000001 (NEEDED)                     Shared library: [libx.so]
0x00000001 (NEEDED)                     Shared library: [libc.so]
...

您可以看到，此测试应用与libx.so和libc.so相关联。 libx.so之前已链接libc.so。

现在，我从调试器运行测试应用程序，我注意到这个调用堆栈：

Breakpoint 1, 0xf7741364 in pthread_mutex_lock () from 
target:/data/local/tmp/libx.so
(gdb) bt
#0  0xf7741364 in pthread_mutex_lock () from target:/data/local/tmp/libx.so
#1  0xf76f5660 in __pthread_internal_add(pthread_internal_t*) () from 
    target:/system/lib/libc.so
...

有趣的是pthread_mutex_lock()是从__pthread_internal_add()内的函数libc.so调用的。在libc.so中，已存在pthread_mutex_lock()函数：

arm-linux-androideabi-nm -g /system/lib/libc.so | grep pthread_mutex_lock
00047a74 T pthread_mutex_lock
...

__pthread_internal_add()内的libc.so不应该同时调用内部函数吗？为什么它从另一个（外部）调用函数呢？

Answer 1

此行为取决于 -bsymbolic 链接器选项。这最近在Android NDK中发生了变化：https://github.com/android-ndk/ndk/wiki/Changelog-r16：

默认情况下，GCC不再使用-Bsymbolic。这允许符合C ++标准规定的符号抢占以及ASAN的要求。对于具有大量公共符号的库，这可能会增加二进制文件的大小。

为什么不调用函数来源一样呢？

1 个答案: