Android Native 中编译的 binary 为什么会存在 SONAME

20次阅读

共计 2414 个字符，预计需要花费 7 分钟才能阅读完成。

最近在移植 AOSP14，遇到一个百思不得其解的问题。在我此前的认知里 binary=executable= 可执行文件，源码实现时一定是以 main 函数作为入口 entry 的，直到今天我发现一个有意思的程序。

前提：
运行环境：AOSP14 Cuttlefish Virtual Machine

该程序位于 /apex/com.android.runtime/bin 目录，我们先用 file 命令看看：

86_64:/apex/com.android.runtime/bin # file linker64
linker64: ELF shared object, 64-bit LSB x86-64, BuildID=c8f402abba648f1ad456bbf0b9cd3e7a, not stripped

看上去正常，我们使用 readelf 查看一下：

86_64:/apex/com.android.runtime/bin # readelf -d linker64 | grep SONAME  
0x000000000000000e (SONAME)             Library soname: [ld-android.so]

这怎么会有个 SONAME 呢，按道理这是个 binary，不是个 shared library, 接着我们再看看其所拥有的 program headers：

86_64:/apex/com.android.runtime/bin # readelf -l linker64

Elf file type is DYN (Shared object file)
Entry point 0x68390
There are 10 program headers, starting at offset 64

Program Headers:
  Type           Offset   VirtAddr           PhysAddr           FileSiz MemSiz  Flg Align
  PHDR           0x000040 0x0000000000000040 0x0000000000000040 0x00230 0x00230 R   0x8
  LOAD           0x000000 0x0000000000000000 0x0000000000000000 0x46b54 0x46b54 R   0x1000
  LOAD           0x046b60 0x0000000000047b60 0x0000000000047b60 0x101e10 0x101e10 R E 0x1000
  LOAD           0x148970 0x000000000014a970 0x000000000014a970 0x087b8 0x087b8 RW  0x1000
  LOAD           0x151140 0x0000000000154140 0x0000000000154140 0x00f70 0x0eae8 RW  0x1000
  DYNAMIC        0x150d90 0x0000000000152d90 0x0000000000152d90 0x00120 0x00120 RW  0x8
  GNU_RELRO      0x148970 0x000000000014a970 0x000000000014a970 0x087b8 0x09690 R   0x1
  GNU_EH_FRAME   0x01c1b4 0x000000000001c1b4 0x000000000001c1b4 0x0633c 0x0633c R   0x4
  GNU_STACK      0x000000 0x0000000000000000 0x0000000000000000 0x00000 0x00000 RW  0
  NOTE           0x000270 0x0000000000000270 0x0000000000000270 0x00020 0x00020 R   0x4

 Section to Segment mapping:
  Segment Sections...
   00
   01     .note.gnu.build-id .dynsym .gnu.hash .dynstr .relr.dyn .rela.plt .rodata .gcc_except_table .eh_frame_hdr .eh_frame
   02     .text .iplt
   03     .data.rel.ro .init_array .dynamic .got .got.plt
   04     .data
   05     .dynamic
   06     .data.rel.ro .init_array .dynamic .got .got.plt
   07     .eh_frame_hdr
   08
   09     .note.gnu.build-id

这里我们没有找到 INTERP 字段，按照这边文章的说法，executable 是应当包含 INTERP 字段的，而 shared library 是不包含的，所以这理应是个 shared library？所以才会有 SONAME.

可是 shared library 是没法直接在 command line 中运行的，但是实际上又可以运行：

x86_64:/apex/com.android.runtime/bin # ./linker64 --help
Usage: ./linker64 [--list] PROGRAM [ARGS-FOR-PROGRAM...]
       ./linker64 [--list] path.zip!/PROGRAM [ARGS-FOR-PROGRAM...]

A helper program for linking dynamic executables. Typically, the kernel loads
this program because it's the PT_INTERP of a dynamic executable.

This program can also be run directly to load and run a dynamic executable. The
executable can be inside a zip file if it's stored uncompressed and at a
page-aligned offset.

The --list option gives behavior equivalent to ldd(1) on other systems.

所以我迷糊了，是我理解产生了偏差了么。

正文完