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

Mon Dec 16 06:37:00 GMT 2019

Hi Xing Hao,

on 2019/12/11 脧脗脦莽5:32, Xing-Hao Chen wrote:
> however, i built another "so" 篓C that linking(depending on) these two so, seems not able to load these two so into proper fixed address, see below -
> ldd ./
> => (0x0000ffff8d87c000)
> => ./ (0x0000ffff89d50000)
> => ./ (0x0000ffff5e350000)
> => /lib/aarch64-linux-gnu/ (0x0000ffff5e31c000)
> => /lib/aarch64-linux-gnu/ (0x0000ffff5e304000)
> => /lib/aarch64-linux-gnu/ (0x0000ffff5e2f0000)
> => /lib/aarch64-linux-gnu/ (0x0000ffff5e23e000)
> => /lib/aarch64-linux-gnu/ (0x0000ffff5e0ea000)
> /lib/ (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 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 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 if you specify -fpie -Wl,-pie when generating appDemo.



> NOK: LD_DEBUG=all ldd ./
>   2349: [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=./
>   2289:
>   2289: [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