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

查看 37|回复 0
作者:FranzKafka95   
最近在移植 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.
所以我迷糊了,是我理解产生了偏差了么。
您需要登录后才可以回帖 登录 | 立即注册

返回顶部