"so"如何使用固定地址加载SO？

Question

在我的程序中，必须将两个"so"-libcpss.so 和 libhelper.so 加载到固定的虚拟地址中， 它是由 LD 脚本完成的，

SECTIONS
{
/* Code section, access rights RX */
. = 0x14600000;
…
}

雷德尔夫 -L libhelper.so | 收起

精灵文件类型是 DYN (共享对象文件( 入口点0x14607ad8 有 8 个程序标头，从偏移量 64 开始

Program Headers:
Type           Offset             VirtAddr           PhysAddr
FileSiz            MemSiz              Flags  Align
LOAD           0x0000000000010000 0x0000000014600000 0x0000000014600000
0x000000000001aaec 0x000000000001aaec  R E    0x10000

一个ELF程序链接了这两个".so"，我们可以看到这两个确实被加载到预期的固定地址中，

ldd ./appDemo

linux-vdso.so.1 => (0x0000ffff917ec000)
libcpss.so => ./libcpss.so (0x0000000010000000)
libhelper.so => ./libhelper.so (0x0000000014600000)
libpthread.so.0 => /lib/aarch64-linux-gnu/libpthread.so.0 (0x0000ffff917b5000)
librt.so.1 => /lib/aarch64-linux-gnu/librt.so.1 (0x0000ffff9179d000)
libdl.so.2 => /lib/aarch64-linux-gnu/libdl.so.2 (0x0000ffff91789000)
libm.so.6 => /lib/aarch64-linux-gnu/libm.so.6 (0x0000ffff916d7000)
libc.so.6 => /lib/aarch64-linux-gnu/libc.so.6 (0x0000ffff91583000)
/lib/ld-linux-aarch64.so.1 (0x0000aaaadd94f000)

但是，我构建了另一个"所以"链接(取决于(这两个所以，似乎无法将这两个加载到正确的固定地址中，见下文 -

ldd ./libtestScript.so

linux-vdso.so.1 => (0x0000ffff8d87c000)
libcpss.so => ./libcpss.so (0x0000ffff89d50000)
libhelper.so => ./libhelper.so (0x0000ffff5e350000)
libpthread.so.0 => /lib/aarch64-linux-gnu/libpthread.so.0 (0x0000ffff5e31c000)
librt.so.1 => /lib/aarch64-linux-gnu/librt.so.1 (0x0000ffff5e304000)
libdl.so.2 => /lib/aarch64-linux-gnu/libdl.so.2 (0x0000ffff5e2f0000)
libm.so.6 => /lib/aarch64-linux-gnu/libm.so.6 (0x0000ffff5e23e000)
libc.so.6 => /lib/aarch64-linux-gnu/libc.so.6 (0x0000ffff5e0ea000)
/lib/ld-linux-aarch64.so.1 (0x0000aaaae0958000)

在建立"联合.so"期间，我是否错过了任何LD标志？ 我看到了 elf 主程序和"联合"之间的唯一区别，所以"-shared"的标志，那么为什么"联合 .so"错过了两个依赖 so 的加载地址的信息呢？ 似乎当 ld.so 加载"联合.so"并尝试解析和加载依赖项两个".so"时，但它不会将它们加载到固定地址(0x10000000/0x14600000(

挪威克朗： LD_DEBUG=所有 ldd ./libtestScript.so

2349:     file=libhelper.so [0];  generating link map
2349:       dynamic: 0x0000ffff5d581ba0  base: 0x0000ffff48f57000   size: 0x000000002b9ff004
2349:         entry: 0x0000ffff5d55ead8  phdr: 0x0000ffff8ca6fcc0  phnum:                  8

还行： LD_DEBUG=all ldd ./appDemo

2289:       trying file=./libhelper.so
2289:
2289:     file=libhelper.so [0];  generating link map
2289:       dynamic: 0x000000001462aba0  base: 0x0000000000000000   size: 0x000000002b9ff004
2289:         entry: 0x0000000014607ad8  phdr: 0x0000ffffb2e24cc0  phnum:                  8

readelf -h ./libhelper.so

ELF Header:
Magic:   7f 45 4c 46 02 01 01 00 00 00 00 00 00 00 00 00 
Class:                             ELF64
Data:                              2's complement, little endian
Version:                           1 (current)
OS/ABI:                            UNIX - System V
ABI Version:                       0
Type:                              DYN (Shared object file)
Machine:                           AArch64
Version:                           0x1
Entry point address:               0x14607ad8
Start of program headers:          64 (bytes into file)
Start of section headers:          228680 (bytes into file)
Flags:                             0x0
Size of this header:               64 (bytes)
Size of program headers:           56 (bytes)
Number of program headers:         8
Size of section headers:           64 (bytes)
Number of section headers:         34
Section header string table index: 31

如果您能帮助我，我将不胜感激。 此致敬意 陈星浩

Answer 1

在生成 libtestScript.so 时添加 -wl，-ttext-segment=0xXXXXXXXXX(例如 0x70000000(的标志后，结果按预期显示：

ldd libtestScript.so
linux-vdso.so.1 (0x0000007fa6f04000)
libcpss.so => ./libcpss.so (0x0000000010000000)
libhelper.so => ./libhelper.so (0x0000000014600000)
libpthread.so.0 => /lib/aarch64-linux-gnu/libpthread.so.0 (0x0000007fa6ece000)
librt.so.1 => /lib/aarch64-linux-gnu/librt.so.1 (0x0000007fa6eb7000)
libdl.so.2 => /lib/aarch64-linux-gnu/libdl.so.2 (0x0000007fa6ea2000)
libm.so.6 => /lib/aarch64-linux-gnu/libm.so.6 (0x0000007fa6de6000)
libc.so.6 => /lib/aarch64-linux-gnu/libc.so.6 (0x0000007fa6c8d000)
/lib/ld-linux-aarch64.so.1 (0x0000005565c4c000)