RE: [EXT] 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 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@xxxxxxxxxxxxx> 
Sent: 2019年12月16日 14:37
To: Xing-Hao Chen <ericxh@xxxxxxxxxxx>; gcc-help@xxxxxxxxxxx
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" ? 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