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

Xing-Hao Chen ericxh@marvell.com
Mon Dec 16 08:14:00 GMT 2019


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
> 



More information about the Gcc-help mailing list