help! why a 'so' can't load its dependent 'so' to the pre-defined address

public inbox for gcc-help@gcc.gnu.org
 help / color / mirror / Atom feed

* help! why a 'so' can't load its dependent 'so' to the pre-defined address
@ 2019-12-11  9:33 Xing-Hao Chen
  2019-12-11 17:06 ` Richard Sandiford
                   ` (2 more replies)
  0 siblings, 3 replies; 7+ messages in thread
From: Xing-Hao Chen @ 2019-12-11  9:33 UTC (permalink / raw)
  To: gcc-help

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="gb2312", Size: 6115 bytes --]

Dear GCC experts

Please forgive me if it¡¯s bothering you.

I have a question about LD and dynamic library, which I have been struggling with for a while
it will be great if you can help me out,

in my program, two "so" - libcpss.so and libhelper.so have to be loaded into a fixed virtual address, it¡¯s done by the ld script,

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

readelf -l libhelper.so | less

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

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

an elf program(appDemo) linked with these two ".so", we can see the two so indeed were loaded into the expected fixed address,

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)

however, i built another "so" ¨C libtestScript.so that linking(depending on) these two so, seems not able to load these two so into proper fixed address, see below -

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)

do i missed any LD flags during building of the ¡°joint .so" ? i saw the only difference between elf main program and ¡°joint¡± so is the flag of ¡°-shared¡±, so why ¡°joint .so" missed the info of the two dependent so¡¯s loading address? seems when the ld.so load "joint .so" and try to resolve and load the dependency two ".so", but it doesn't load them into the fixed address(0x10000000 / 0x14600000)

NOK: LD_DEBUG=all 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

OK: 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

i appreciate if you can help me out.

For your reference on how I built the elf executable program and shared lib.
/home/ericxh/work/toolchain/marvell-gcc-5.2.1-16.02.0-armv8/armv8/le/aarch64v8-
marvell-linux-gnu-5.2.1_i686_20151110/bin/aarch64-marvell-linux-gnu-gcc  -shared
-Xlinker                                                         --whole-archive
compilation_root/cpss_4.2/armv8_DX_SHARED/cpssEnabler/libs/TESTSCRIPT.a -Xlinker
--no-whole-archive    \     compilation_root/cpss_4.2/armv8_DX_SHARED/libcpss.so
compilation_root/cpss_4.2/armv8_DX_SHARED/libhelper.so   -Xlinker   -z  -Xlinker
nocopyreloc  -rdynamic   -lpthread  -lrt   -ldl  -lm    -Xlinker  -Map  -Xlinker
compilation_root/cpss_4.2/armv8_DX_SHARED/libtestScript.map \ -Xlinker -soname -
Xlinker                           libtestScript.so                            -o
compilation_root/cpss_4.2/armv8_DX_SHARED/libtestScript.so


/home/ericxh/work/toolchain/marvell-gcc-5.2.1-16.02.0-armv8/armv8/le/aarch64v8-
marvell-linux-gnu-5.2.1_i686_20151110/bin/aarch64-marvell-linux-gnu-gcc -Xlinker
--whole-archive
compilation_root/cpss_4.2/armv8_DX_SHARED/referenceCode/libs/REFERENCECODE.a
¡
¡
compilation_root/cpss_4.2/armv8_DX_SHARED/cpssEnabler/libs/CPSSAPPREF.a
compilation_root/cpss_4.2/armv8_DX_SHARED/version_info.o  -Xlinker   --no-whole-
archive          \          compilation_root/cpss_4.2/armv8_DX_SHARED/libcpss.so
compilation_root/cpss_4.2/armv8_DX_SHARED/libhelper.so   -Xlinker   -z  -Xlinker
nocopyreloc  -rdynamic   -lpthread  -lrt   -ldl  -lm    -Xlinker  -Map  -Xlinker
compilation_root/cpss_4.2/armv8_DX_SHARED/appDemo.map                         -o
compilation_root/cpss_4.2/armv8_DX_SHARED/appDemo





Best regards

Xinghao Chen £¨³ÂÐÐºÆ£©


^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: help! why a 'so' can't load its dependent 'so' to the pre-defined address
  2019-12-11  9:33 help! why a 'so' can't load its dependent 'so' to the pre-defined address Xing-Hao Chen
@ 2019-12-11 17:06 ` Richard Sandiford
  2019-12-12  8:18 ` Xing-Hao Chen
  2019-12-16  6:37 ` Kewen.Lin
  2 siblings, 0 replies; 7+ messages in thread
From: Richard Sandiford @ 2019-12-11 17:06 UTC (permalink / raw)
  To: Xing-Hao Chen; +Cc: gcc-help

Hi,

Xing-Hao Chen <ericxh@marvell.com> writes:
> Dear GCC experts
>
> Please forgive me if it’s bothering you.
>
> I have a question about LD and dynamic library, which I have been struggling with for a while
> it will be great if you can help me out,
>
> in my program, two "so" - libcpss.so and libhelper.so have to be loaded into a fixed virtual address, it’s done by the ld script,
>
> SECTIONS
> {
> /* Code section, access rights RX */
> . = 0x14600000;
> …
> }
>
> readelf -l libhelper.so | less
>
> Elf file type is DYN (Shared object file) Entry point 0x14607ad8 There are 8 program headers, starting at offset 64
>
> Program Headers:
>   Type           Offset             VirtAddr           PhysAddr
>                  FileSiz            MemSiz              Flags  Align
>   LOAD           0x0000000000010000 0x0000000014600000 0x0000000014600000
>                  0x000000000001aaec 0x000000000001aaec  R E    0x10000
>
> an elf program(appDemo) linked with these two ".so", we can see the two so indeed were loaded into the expected fixed address,

I might be wrong, but I don't think there's any supported way of
forcing the DSO to be loaded at this address.  The dynamic linker
can load DSOs at whichever address is convenient, and it expects
to be able to relocate DSOs as necessary.

That's probably not very useful to you, sorry.

Richard

>
> 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)
>
> however, i built another "so" – libtestScript.so that linking(depending on) these two so, seems not able to load these two so into proper fixed address, see below -
>
> 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)
>
> do i missed any LD flags during building of the “joint .so" ? i saw the only difference between elf main program and “joint” so is the flag of “-shared”, so why “joint .so" missed the info of the two dependent so’s loading address? seems when the ld.so load "joint .so" and try to resolve and load the dependency two ".so", but it doesn't load them into the fixed address(0x10000000 / 0x14600000)
>
> NOK: LD_DEBUG=all 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
>
> OK: 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
>
> i appreciate if you can help me out.
>
> For your reference on how I built the elf executable program and shared lib.
> /home/ericxh/work/toolchain/marvell-gcc-5.2.1-16.02.0-armv8/armv8/le/aarch64v8-
> marvell-linux-gnu-5.2.1_i686_20151110/bin/aarch64-marvell-linux-gnu-gcc  -shared
> -Xlinker                                                         --whole-archive
> compilation_root/cpss_4.2/armv8_DX_SHARED/cpssEnabler/libs/TESTSCRIPT.a -Xlinker
> --no-whole-archive    \     compilation_root/cpss_4.2/armv8_DX_SHARED/libcpss.so
> compilation_root/cpss_4.2/armv8_DX_SHARED/libhelper.so   -Xlinker   -z  -Xlinker
> nocopyreloc  -rdynamic   -lpthread  -lrt   -ldl  -lm    -Xlinker  -Map  -Xlinker
> compilation_root/cpss_4.2/armv8_DX_SHARED/libtestScript.map \ -Xlinker -soname -
> Xlinker                           libtestScript.so                            -o
> compilation_root/cpss_4.2/armv8_DX_SHARED/libtestScript.so
>
>
> /home/ericxh/work/toolchain/marvell-gcc-5.2.1-16.02.0-armv8/armv8/le/aarch64v8-
> marvell-linux-gnu-5.2.1_i686_20151110/bin/aarch64-marvell-linux-gnu-gcc -Xlinker
> --whole-archive
> compilation_root/cpss_4.2/armv8_DX_SHARED/referenceCode/libs/REFERENCECODE.a
> …
> …
> compilation_root/cpss_4.2/armv8_DX_SHARED/cpssEnabler/libs/CPSSAPPREF.a
> compilation_root/cpss_4.2/armv8_DX_SHARED/version_info.o  -Xlinker   --no-whole-
> archive          \          compilation_root/cpss_4.2/armv8_DX_SHARED/libcpss.so
> compilation_root/cpss_4.2/armv8_DX_SHARED/libhelper.so   -Xlinker   -z  -Xlinker
> nocopyreloc  -rdynamic   -lpthread  -lrt   -ldl  -lm    -Xlinker  -Map  -Xlinker
> compilation_root/cpss_4.2/armv8_DX_SHARED/appDemo.map                         -o
> compilation_root/cpss_4.2/armv8_DX_SHARED/appDemo
>
>
>
>
>
> Best regards
>
> Xinghao Chen （陈行浩）

^ permalink raw reply	[flat|nested] 7+ messages in thread

* RE: help! why a 'so' can't load its dependent 'so' to the pre-defined address
  2019-12-11  9:33 help! why a 'so' can't load its dependent 'so' to the pre-defined address Xing-Hao Chen
  2019-12-11 17:06 ` Richard Sandiford
@ 2019-12-12  8:18 ` Xing-Hao Chen
  2019-12-16  6:37 ` Kewen.Lin
  2 siblings, 0 replies; 7+ messages in thread
From: Xing-Hao Chen @ 2019-12-12  8:18 UTC (permalink / raw)
  To: gcc-help


why ld.so loading EXEC/DYN elf behaves differently in term of the same dependent so?
EXEC – loading dependency so according to So ELF header (fixed virtual address which is defined by LD script during creating of the so)
DYN  - loading dependency so randomly.

Appreciate if someone could help. 😊

Xinghao Chen （陈行浩）

From: Xing-Hao Chen
Sent: 2019年12月11日 17:33
To: gcc-help@gcc.gnu.org
Subject: help! why a 'so' can't load its dependent 'so' to the pre-defined address

Dear GCC experts

Please forgive me if it’s bothering you.

I have a question about LD and dynamic library, which I have been struggling with for a while
it will be great if you can help me out,

in my program, two "so" - libcpss.so and libhelper.so have to be loaded into a fixed virtual address, it’s done by the ld script,

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

readelf -l libhelper.so | less

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

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

an elf program(appDemo) linked with these two ".so", we can see the two so indeed were loaded into the expected fixed address,

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)

however, i built another "so" – libtestScript.so that linking(depending on) these two so, seems not able to load these two so into proper fixed address, see below -

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)

do i missed any LD flags during building of the “joint .so" ? i saw the only difference between elf main program and “joint” so is the flag of “-shared”, so why “joint .so" missed the info of the two dependent so’s loading address? seems when the ld.so load "joint .so" and try to resolve and load the dependency two ".so", but it doesn't load them into the fixed address(0x10000000 / 0x14600000)

NOK: LD_DEBUG=all 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

OK: 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

i appreciate if you can help me out.

For your reference on how I built the elf executable program and shared lib.
/home/ericxh/work/toolchain/marvell-gcc-5.2.1-16.02.0-armv8/armv8/le/aarch64v8-
marvell-linux-gnu-5.2.1_i686_20151110/bin/aarch64-marvell-linux-gnu-gcc  -shared
-Xlinker                                                         --whole-archive
compilation_root/cpss_4.2/armv8_DX_SHARED/cpssEnabler/libs/TESTSCRIPT.a -Xlinker
--no-whole-archive    \     compilation_root/cpss_4.2/armv8_DX_SHARED/libcpss.so
compilation_root/cpss_4.2/armv8_DX_SHARED/libhelper.so   -Xlinker   -z  -Xlinker
nocopyreloc  -rdynamic   -lpthread  -lrt   -ldl  -lm    -Xlinker  -Map  -Xlinker
compilation_root/cpss_4.2/armv8_DX_SHARED/libtestScript.map \ -Xlinker -soname -
Xlinker                           libtestScript.so                            -o
compilation_root/cpss_4.2/armv8_DX_SHARED/libtestScript.so


/home/ericxh/work/toolchain/marvell-gcc-5.2.1-16.02.0-armv8/armv8/le/aarch64v8-
marvell-linux-gnu-5.2.1_i686_20151110/bin/aarch64-marvell-linux-gnu-gcc -Xlinker
--whole-archive
compilation_root/cpss_4.2/armv8_DX_SHARED/referenceCode/libs/REFERENCECODE.a
…
…
compilation_root/cpss_4.2/armv8_DX_SHARED/cpssEnabler/libs/CPSSAPPREF.a
compilation_root/cpss_4.2/armv8_DX_SHARED/version_info.o  -Xlinker   --no-whole-
archive          \          compilation_root/cpss_4.2/armv8_DX_SHARED/libcpss.so
compilation_root/cpss_4.2/armv8_DX_SHARED/libhelper.so   -Xlinker   -z  -Xlinker
nocopyreloc  -rdynamic   -lpthread  -lrt   -ldl  -lm    -Xlinker  -Map  -Xlinker
compilation_root/cpss_4.2/armv8_DX_SHARED/appDemo.map                         -o
compilation_root/cpss_4.2/armv8_DX_SHARED/appDemo





Best regards

Xinghao Chen （陈行浩）


^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: help! why a 'so' can't load its dependent 'so' to the pre-defined address
  2019-12-11  9:33 help! why a 'so' can't load its dependent 'so' to the pre-defined address Xing-Hao Chen
  2019-12-11 17:06 ` Richard Sandiford
  2019-12-12  8:18 ` Xing-Hao Chen
@ 2019-12-16  6:37 ` Kewen.Lin
  2019-12-16  8:14   ` [EXT] " Xing-Hao Chen
  2 siblings, 1 reply; 7+ messages in thread
From: Kewen.Lin @ 2019-12-16  6:37 UTC (permalink / raw)
  To: Xing-Hao Chen, gcc-help

Hi Xing Hao,

on 2019/12/11 脧脗脦莽5:32, Xing-Hao Chen wrote:
> 
> however, i built another "so" 篓C libtestScript.so that linking(depending on) these two so, seems not able to load these two so into proper fixed address, see below -
> 
> 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)
> 
> do i missed any LD flags during building of the 隆掳joint .so" ? i saw the only difference between elf main program and 隆掳joint隆卤 so is the flag of 隆掳-shared隆卤, so why 隆掳joint .so" missed the info of the two dependent so隆炉s loading address? seems when the ld.so load "joint .so" and try to resolve and load the dependency two ".so", but it doesn't load them into the fixed address(0x10000000 / 0x14600000)

I found that if you force the virtual address for the libtestScript.so generation as well, you can see the expected result
you wanted.  I have no idea about how loader gets it internally, but I guess if the module which requires some others to be loaded, doesn't have the forced vaddr, the modules it relies on would be handled in the same way.

As to the question why the executable behaves differently.  I think it's due to the default option to generate final executable is -pie.  You will see the same behavior as libtestScript.so if you specify -fpie -Wl,-pie when generating appDemo.

HTH.

BR,
Kewen

> 
> NOK: LD_DEBUG=all 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
> 
> OK: 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
> 

^ permalink raw reply	[flat|nested] 7+ messages in thread

* RE: [EXT] Re: help! why a 'so' can't load its dependent 'so' to the pre-defined address
  2019-12-16  6:37 ` Kewen.Lin
@ 2019-12-16  8:14   ` Xing-Hao Chen
  2019-12-17  2:42     ` Kewen.Lin
  0 siblings, 1 reply; 7+ messages in thread
From: Xing-Hao Chen @ 2019-12-16  8:14 UTC (permalink / raw)
  To: Kewen.Lin, gcc-help

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="gb2312", Size: 3632 bytes --]

Hi Kewen,
Appreciate very much for your reply,
 
"I found that if you force the virtual address for the libtestScript.so generation as well, you can see the expected result you wanted."

But how to force the VA for libtestScript.so? 
I tried "-Wl,-Ttext=0xXXXX", but will suffer some link problems. 
How can I assign the 0xXXXX, while fixing the load VA of libcpss.so/libhelper.so(to be 0x10000000 / 0x14600000) which libtestScript.so relies on?

In summary of my requirement -
When loading libtestScript.so, the loader should load its dependent two so(libcpss.so/libhelper.so) into the pre-defined VA(to be 0x10000000 / 0x14600000)

How can I do?  Any suggestion is appreciated. 

Xinghao Chen £¨³ÂÐÐºÆ£© 

-----Original Message-----
From: Kewen.Lin <linkw@linux.ibm.com> 
Sent: 2019Äê12ÔÂ16ÈÕ 14:37
To: Xing-Hao Chen <ericxh@marvell.com>; gcc-help@gcc.gnu.org
Subject: [EXT] Re: help! why a 'so' can't load its dependent 'so' to the pre-defined address

External Email

----------------------------------------------------------------------
Hi Xing Hao,

on 2019/12/11 ÏÂÎç5:32, Xing-Hao Chen wrote:
> 
> however, i built another "so" ¨C libtestScript.so that 
> linking(depending on) these two so, seems not able to load these two 
> so into proper fixed address, see below -
> 
> 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)
> 
> do i missed any LD flags during building of the ¡°joint .so" ? i saw 
> the only difference between elf main program and ¡°joint¡± so is the 
> flag of ¡°-shared¡±, so why ¡°joint .so" missed the info of the two 
> dependent so¡¯s loading address? seems when the ld.so load "joint .so" 
> and try to resolve and load the dependency two ".so", but it doesn't 
> load them into the fixed address(0x10000000 / 0x14600000)

I found that if you force the virtual address for the libtestScript.so generation as well, you can see the expected result you wanted.  I have no idea about how loader gets it internally, but I guess if the module which requires some others to be loaded, doesn't have the forced vaddr, the modules it relies on would be handled in the same way.

As to the question why the executable behaves differently.  I think it's due to the default option to generate final executable is -pie.  You will see the same behavior as libtestScript.so if you specify -fpie -Wl,-pie when generating appDemo.

HTH.

BR,
Kewen

> 
> NOK: LD_DEBUG=all 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
> 
> OK: 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
> 


^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [EXT] Re: help! why a 'so' can't load its dependent 'so' to the pre-defined address
  2019-12-16  8:14   ` [EXT] " Xing-Hao Chen
@ 2019-12-17  2:42     ` Kewen.Lin
  2019-12-17  6:57       ` Xing-Hao Chen
  0 siblings, 1 reply; 7+ messages in thread
From: Kewen.Lin @ 2019-12-17  2:42 UTC (permalink / raw)
  To: Xing-Hao Chen, gcc-help

on 2019/12/16 脧脗脦莽4:13, Xing-Hao Chen wrote:
> Hi Kewen,
> Appreciate very much for your reply,
>  
> "I found that if you force the virtual address for the libtestScript.so generation as well, you can see the expected result you wanted."
> 
> But how to force the VA for libtestScript.so? 
> I tried "-Wl,-Ttext=0xXXXX", but will suffer some link problems. 
> How can I assign the 0xXXXX, while fixing the load VA of libcpss.so/libhelper.so(to be 0x10000000 / 0x14600000) which libtestScript.so relies on?
> 

Hi,

I think you can still use linker script scheme for libtestScript.so generation like what you have for libcpss.so/libhelper.so.  I used linker script for libt1.so libt3.so generation and see the ldd dump as below.  Here libt3 is like libtestScript.so, libt1 is like libcpss.so/libhelper.so and libt2 is as normal.

$ LD_LIBRARY_PATH=. ldd ./libt3.so
        linux-vdso64.so.1 =>  (0x00003fffadb40000)
        libt1.so => ./libt1.so (0x0000020000000000)
        libt2.so => ./libt2.so (0x00003fffadb10000)
        libc.so.6 => /lib/powerpc64le-linux-gnu/libc.so.6 (0x00003fffad910000)
        /lib64/ld64.so.2 (0x00003fffadb60000)

** simple ld scripts **
ld01.txt:
  SECTIONS
  {
    . = 0x20000000000;
    .text : { *(.text) }
  }
ld03.txt:
SECTIONS
  {
    . = 0x40000000000;
    .text : { *(.text) }
  }

PS: above scripts are really simple, just for proof of concepts.

** commands **
gcc -shared -fPIC t1.c -o libt1.so -Tld01.txt
gcc -shared -fPIC t2.c -o libt2.so
gcc -shared -fPIC t3.c -o libt3.so -Tld03.txt -L. -lt1 -lt2 -Wl,-R.
gcc main.c -L. -lt3

Note that you need to avoid that the module libtestScript.so conflicts with libcpss.so/libhelper.so, for example using ld01.txt for libt3.so generation, it gets the dumping as below.

$ LD_LIBRARY_PATH=. ldd ./libt3.so
        linux-vdso64.so.1 =>  (0x00003fffb0550000)
        libt1.so => ./libt1.so (0x00003fffa0540000)
        libt2.so => ./libt2.so (0x00003fffa0510000)
        libc.so.6 => /lib/powerpc64le-linux-gnu/libc.so.6 (0x00003fffa0310000)
        /lib64/ld64.so.2 (0x00003fffb0570000)

** simple src **
t1.c:
  int t1(int a, int b) { return a + b; }
t2.c:
  int t2(int a, int b) { return a - b; }
t3.c:
  extern int t1(int a, int b);
  extern int t2(int a, int b);
  int t3(int a, int b){
    return t1(a, b) + t2(b, a);
  }
main.c:
  extern int t3(int a, int b);
  int main() {
    int a = 1;
    int b = 2;
    int c = t3(a+b, b-a);
    return c;
  }

I tested it on powerpc64le-linux-gnu, with gcc 5.4.0 and GNU ld 2.26.1, FYI in case it matters.

BR,
Kewen

> In summary of my requirement -
> When loading libtestScript.so, the loader should load its dependent two so(libcpss.so/libhelper.so) into the pre-defined VA(to be 0x10000000 / 0x14600000)
> 
> How can I do?  Any suggestion is appreciated. 
> 

^ permalink raw reply	[flat|nested] 7+ messages in thread

* RE: [EXT] Re: help! why a 'so' can't load its dependent 'so' to the pre-defined address
  2019-12-17  2:42     ` Kewen.Lin
@ 2019-12-17  6:57       ` Xing-Hao Chen
  0 siblings, 0 replies; 7+ messages in thread
From: Xing-Hao Chen @ 2019-12-17  6:57 UTC (permalink / raw)
  To: Kewen.Lin, gcc-help

Hi Kewen,

Thanks for your detailed instructions, 
Following your idea, but with a minor difference, instead of -T scriptfile, I am using -Wl,-Ttext-segment=0xXXXXXXXX(e.g. 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)

readelf -h libtestScript.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:               0x70000840
  Start of program headers:          64 (bytes into file)
  Start of section headers:          7248 (bytes into file)
  Flags:                             0x0
  Size of this header:               64 (bytes)
  Size of program headers:           56 (bytes)
  Number of program headers:         6
  Size of section headers:           64 (bytes)
  Number of section headers:         28
  Section header string table index: 25


Cheers, 
Kewen, appreciate so much for your kind help !!!


Xinghao Chen （陈行浩）

-----Original Message-----
From: Kewen.Lin <linkw@linux.ibm.com> 
Sent: 2019年12月17日 10:42
To: Xing-Hao Chen <ericxh@marvell.com>; gcc-help@gcc.gnu.org
Subject: Re: [EXT] Re: help! why a 'so' can't load its dependent 'so' to the pre-defined address

on 2019/12/16 下午4:13, Xing-Hao Chen wrote:
> Hi Kewen,
> Appreciate very much for your reply,
>  
> "I found that if you force the virtual address for the libtestScript.so generation as well, you can see the expected result you wanted."
> 
> But how to force the VA for libtestScript.so? 
> I tried "-Wl,-Ttext=0xXXXX", but will suffer some link problems. 
> How can I assign the 0xXXXX, while fixing the load VA of libcpss.so/libhelper.so(to be 0x10000000 / 0x14600000) which libtestScript.so relies on?
> 

Hi,

I think you can still use linker script scheme for libtestScript.so generation like what you have for libcpss.so/libhelper.so.  I used linker script for libt1.so libt3.so generation and see the ldd dump as below.  Here libt3 is like libtestScript.so, libt1 is like libcpss.so/libhelper.so and libt2 is as normal.

$ LD_LIBRARY_PATH=. ldd ./libt3.so
        linux-vdso64.so.1 =>  (0x00003fffadb40000)
        libt1.so => ./libt1.so (0x0000020000000000)
        libt2.so => ./libt2.so (0x00003fffadb10000)
        libc.so.6 => /lib/powerpc64le-linux-gnu/libc.so.6 (0x00003fffad910000)
        /lib64/ld64.so.2 (0x00003fffadb60000)

** simple ld scripts **
ld01.txt:
  SECTIONS
  {
    . = 0x20000000000;
    .text : { *(.text) }
  }
ld03.txt:
SECTIONS
  {
    . = 0x40000000000;
    .text : { *(.text) }
  }

PS: above scripts are really simple, just for proof of concepts.

** commands **
gcc -shared -fPIC t1.c -o libt1.so -Tld01.txt gcc -shared -fPIC t2.c -o libt2.so gcc -shared -fPIC t3.c -o libt3.so -Tld03.txt -L. -lt1 -lt2 -Wl,-R.
gcc main.c -L. -lt3

Note that you need to avoid that the module libtestScript.so conflicts with libcpss.so/libhelper.so, for example using ld01.txt for libt3.so generation, it gets the dumping as below.

$ LD_LIBRARY_PATH=. ldd ./libt3.so
        linux-vdso64.so.1 =>  (0x00003fffb0550000)
        libt1.so => ./libt1.so (0x00003fffa0540000)
        libt2.so => ./libt2.so (0x00003fffa0510000)
        libc.so.6 => /lib/powerpc64le-linux-gnu/libc.so.6 (0x00003fffa0310000)
        /lib64/ld64.so.2 (0x00003fffb0570000)

** simple src **
t1.c:
  int t1(int a, int b) { return a + b; }
t2.c:
  int t2(int a, int b) { return a - b; }
t3.c:
  extern int t1(int a, int b);
  extern int t2(int a, int b);
  int t3(int a, int b){
    return t1(a, b) + t2(b, a);
  }
main.c:
  extern int t3(int a, int b);
  int main() {
    int a = 1;
    int b = 2;
    int c = t3(a+b, b-a);
    return c;
  }

I tested it on powerpc64le-linux-gnu, with gcc 5.4.0 and GNU ld 2.26.1, FYI in case it matters.

BR,
Kewen

> In summary of my requirement -
> When loading libtestScript.so, the loader should load its dependent 
> two so(libcpss.so/libhelper.so) into the pre-defined VA(to be 
> 0x10000000 / 0x14600000)
> 
> How can I do?  Any suggestion is appreciated. 
> 


^ permalink raw reply	[flat|nested] 7+ messages in thread

end of thread, other threads:[~2019-12-17  6:57 UTC | newest]

Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-12-11  9:33 help! why a 'so' can't load its dependent 'so' to the pre-defined address Xing-Hao Chen
2019-12-11 17:06 ` Richard Sandiford
2019-12-12  8:18 ` Xing-Hao Chen
2019-12-16  6:37 ` Kewen.Lin
2019-12-16  8:14   ` [EXT] " Xing-Hao Chen
2019-12-17  2:42     ` Kewen.Lin
2019-12-17  6:57       ` Xing-Hao Chen

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).