How to upload two .so which are depended on each other

[Wile_E_Coyote]

How to upload two .so which are depended on each other

AFAIK, you cannot enforce a specific fixed address when loading libraries on demand at runtime (e.g. this address may already be used by another library which has been loaded earlier). I think, you would need to recreate the main “${ROOTSYS}/bin/root.exe” executable (or the “cling” executable, if you use it), explicitly linking it against your special library and using your special ld script.

[Axel]

cling uses dlopen to load your library.

Please hand in a pull request if there is something you’d like to see improved on cling’s side. Your use case is niche enough that you won’t find a lot of help here I’m afraid.

Cheers, Axel.

[ericxh]

Hi Axel & Wile_E

sorry to bother you so much.
i did get valuable suggestion from you. i appreciate it very much.

eventually i might find the reason,
it’s due to different gcc i use to generate my program(via cross toolchain) and cling(via armv8 native GCC)

the main difference is the armv8 native GCC is built-in with “–enable-default-pie”,

file appDemo
appDemo: ELF 64-bit LSB executable, ARM aarch64, version 1 (SYSV), dynamically linked, interpreter /lib/ld-, for GNU/Linux 3.7.0, BuildID[sha1]=3c53df2ba4bc6b8408718d893553545f5c7b55e5, not stripped

file cling
cling： ELF 64-bit LSB shared object, ARM aarch64, version 1 (GNU/Linux), dynamically linked, interpreter /lib/ld-, for GNU/Linux 3.7.0, BuildID[sha1]=afebc34b4e2098c74ded19b2b58f039340e45578, not stripped

i believe i am very closed to the problem fix.
so the last questions –

1. can cling project support to build with cross compiler ? if yes, how to?
   now i am using native armv8 machine to build cling with target of aarch64-linux-gnu
2. would you mind to guide me how to put “-no-pie” in the CFLAGS in the cling project?

Thanks a lot.
Xinghao Chen

[Axel]

1. I never tried cross-compilation but there are reports that it can be made to work. Patches welcome.

2. cling’s JIT needs fPIC (which IIRC is related to pie?) to resolve symbols.

[ericxh]

Thanks Axel for your answers

i tried below -
cmake -DCMAKE_EXE_LINKER_FLAGS=-no-pie

and it works on X86 native compiler,
file cling
cling: ELF 64-bit LSB executable, x86-64, version 1 (GNU/Linux), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 3.2.0, BuildID[sha1]=d32341d565394b1dd15f033785de95d7171ed890, not stripped

previously it’s “LSB shared object”
basically, cling is working with my program on x86 platform.

as for aarch64, there is some problem during the last link, but i believe it might be other issue of gcc.

so i think i can close this topic.
Thanks again for Wile_E & Axel 's help on me - a newbie’s question.

Xinghao Chen

[ericxh]

aarch64 is working now as well.
ticket closed.

[Wile_E_Coyote]

Maybe you could write here some recipe (separately for x86 and arm) so that someone who meets this problem in future would not need to fight with it.

[ericxh]

Thanks Wile_E, my pleasure.

no difference for x86 and aarch64, just did
cmake -DCMAKE_EXE_LINKER_FLAGS=-no-pie
to change the target from “LSB shared” object to “LSB executable”.

when the program is “LSB executable", its dependency “so” if generated with link script to define the text segment address, will be loaded into the pre-defined address,
otherwise they are loaded into random address by the loader (more details please refer to ASLR, -pie)

Thanks
Xinghao Chen

[Wile_E_Coyote]

When you build the “cling” executable, maybe with some clever linker script you could “reserve” some address range which you later plan to use for your special shared libraries.

[ericxh]

yeah,
another simple way is as your proposal before,
to use LD_PRELOAD=xxxx, which will make sure my special “so” will be loaded first, so no overlap happens.

Thanks
Xinghao Chen

[ericxh]

HI Wile_E,

still has some problem, but i believe it’s the last shot.
i defined my “joint” so: libtestScript.so to be loaded into 0x05000000
dependency so - libcpss.so(0x10000000), libhelper.so(0x14600000).

with the same so, but i load them from cling for many times, sounds like the behavior is not deterministic,
sometime it’s good -

00400000-04048000 r-xp 00000000 08:04 2661448 /mnt/usb/work/git_work/interpreter/inst_aarch64/bin/cling
04058000-0445e000 r–p 03c48000 08:04 2661448 /mnt/usb/work/git_work/interpreter/inst_aarch64/bin/cling
0445e000-044d2000 rw-p 0404e000 08:04 2661448 /mnt/usb/work/git_work/interpreter/inst_aarch64/bin/cling
044d2000-0451d000 rw-p 00000000 00:00 0
05000000-05001000 r-xp 00000000 08:04 2509935 /mnt/usb/work/git_work/marvell/cpss/libtestScript.so
05001000-05010000 —p 00001000 08:04 2509935 /mnt/usb/work/git_work/marvell/cpss/libtestScript.so
05010000-05011000 r–p 00000000 08:04 2509935 /mnt/usb/work/git_work/marvell/cpss/libtestScript.so
05011000-05012000 rw-p 00001000 08:04 2509935 /mnt/usb/work/git_work/marvell/cpss/libtestScript.so
0baa8000-0bdbc000 rw-p 00000000 00:00 0 [heap]
10000000-110ba000 r-xp 00010000 08:04 2509933 /mnt/usb/work/git_work/marvell/cpss/libcpss.so
110ba000-110c9000 —p 010ca000 08:04 2509933 /mnt/usb/work/git_work/marvell/cpss/libcpss.so
110c9000-110e2000 rw-p 010c9000 08:04 2509933 /mnt/usb/work/git_work/marvell/cpss/libcpss.so
110e2000-13000000 —p 010f2000 08:04 2509933 /mnt/usb/work/git_work/marvell/cpss/libcpss.so
13000000-13b18000 rw-s 00000000 00:10 9250 /dev/shm/CPSS_SHM_DATA1007
14600000-14619000 r-xp 00010000 08:04 2509934 /mnt/usb/work/git_work/marvell/cpss/libhelper.so
14619000-14628000 —p 00029000 08:04 2509934 /mnt/usb/work/git_work/marvell/cpss/libhelper.so
14628000-14629000 rw-p 00028000 08:04 2509934 /mnt/usb/work/git_work/marvell/cpss/libhelper.so
14629000-1462a000 rw-p 00000000 00:00 0
1462a000-14680000 —p 0003a000 08:04 2509934 /mnt/usb/work/git_work/marvell/cpss/libhelper.so
14680000-14681000 rw-s 00000000 00:10 9251 /dev/shm/MAINOS_SHM_DATA1007
14681000-14800000 —p 00091000 08:04 2509934 /mnt/usb/work/git_work/marvell/cpss/libhelper.so
14800000-34800000 rw-s 00000000 00:10 9252 /dev/shm/CPSS_SHM_MALLOC1007
34800000-5ffff000 —p 20210000 08:04 2509934 /mnt/usb/work/git_work/marvell/cpss/libhelper.so
5ffff000-60000000 rw-p 00000000 00:00 0

sometime it’s bad,
00400000-04048000 r-xp 00000000 08:04 2661448 /mnt/usb/work/git_work/interpreter/inst_aarch64/bin/cling
04058000-0445e000 r–p 03c48000 08:04 2661448 /mnt/usb/work/git_work/interpreter/inst_aarch64/bin/cling
0445e000-044d2000 rw-p 0404e000 08:04 2661448 /mnt/usb/work/git_work/interpreter/inst_aarch64/bin/cling
044d2000-0451d000 rw-p 00000000 00:00 0
05000000-05001000 r-xp 00000000 08:04 2509935 /mnt/usb/work/git_work/marvell/cpss/libtestScript.so
05001000-05010000 —p 00001000 08:04 2509935 /mnt/usb/work/git_work/marvell/cpss/libtestScript.so
05010000-05011000 r–p 00000000 08:04 2509935 /mnt/usb/work/git_work/marvell/cpss/libtestScript.so
05011000-05012000 rw-p 00001000 08:04 2509935 /mnt/usb/work/git_work/marvell/cpss/libtestScript.so
10000000-110ba000 r-xp 00010000 08:04 2509933 /mnt/usb/work/git_work/marvell/cpss/libcpss.so
110ba000-110c9000 —p 010ca000 08:04 2509933 /mnt/usb/work/git_work/marvell/cpss/libcpss.so
110c9000-110e2000 rw-p 010c9000 08:04 2509933 /mnt/usb/work/git_work/marvell/cpss/libcpss.so
110e2000-13000000 —p 010f2000 08:04 2509933 /mnt/usb/work/git_work/marvell/cpss/libcpss.so
13000000-134f1000 rw-p 010f0000 08:04 2509933 /mnt/usb/work/git_work/marvell/cpss/libcpss.so
134f1000-13b18000 rw-p 00000000 00:00 0
3ff1a000-4022e000 rw-p 00000000 00:00 0 [heap]
ffff54352000-ffff5436b000 r-xp 00010000 08:04 2509934 /mnt/usb/work/git_work/marvell/cpss/libhelper.so
ffff5436b000-ffff5437a000 —p 00029000 08:04 2509934 /mnt/usb/work/git_work/marvell/cpss/libhelper.so
ffff5437a000-ffff5437b000 rw-p 00028000 08:04 2509934 /mnt/usb/work/git_work/marvell/cpss/libhelper.so
ffff5437b000-ffff5437c000 rw-p 00000000 00:00 0
ffff5437c000-ffff543d2000 —p 0003a000 08:04 2509934 /mnt/usb/work/git_work/marvell/cpss/libhelper.so
ffff543d2000-ffff543d3000 rw-p 00030000 08:04 2509934 /mnt/usb/work/git_work/marvell/cpss/libhelper.so
ffff543d3000-ffff9fd51000 —p 00091000 08:04 2509934 /mnt/usb/work/git_work/marvell/cpss/libhelper.so
ffff9fd51000-ffff9fd52000 rw-p 00000000 00:00 0

the difference is that cling can’t guarantee to load the two so 100% to the fixed address, 0x10000000 and 0x14600000.

if cling use dlopen() to load “so”, what might be relevant?

but ld.so always show correctly.
/lib/ld-linux-aarch64.so.1 --list ./libtestScript.so
linux-vdso.so.1 (0x0000ffff9b0f2000)
libcpss.so => ./libcpss.so (0x0000000010000000)
libhelper.so => ./libhelper.so (0x0000000014600000)
libc.so.6 => /lib/aarch64-linux-gnu/libc.so.6 (0x0000ffff9af86000)
/lib/ld-linux-aarch64.so.1 (0x0000aaaacf7fb000)

any suggestion is appreciated.

Xinghao Chen

[Wile_E_Coyote]

Well, “address space layout randomization” is actually the expected behaviour.

Try if you get “deterministic” behaviour with LD_PRELOAD.

[ericxh]

Wile_E,

Thanks for your great help.
after disable the ASLR by below, it works .
sysctl -w kernel.randomize_va_space=0

this is exactly what i expected result !!

i tried LD_PRELOAD, but since my so has some dependency on other dynamic lib, it might cause symbol lookup error.

anyway - disable ASLR can help,
really appreciate your kindness help.

i am enjoying cling in my program. great tool, cheers.

Best regards
Xinghao Chen