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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Xing Hao,

on 2019/12/11 下午5:32, Xing-Hao Chen wrote:
> 
> 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)

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
> 




[Index of Archives]     [Linux C Programming]     [Linux Kernel]     [eCos]     [Fedora Development]     [Fedora Announce]     [Autoconf]     [The DWARVES Debugging Tools]     [Yosemite Campsites]     [Yosemite News]     [Linux GCC]

  Powered by Linux