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

Wile_E_Coyote · December 19, 2019, 7:07am

Axel · December 19, 2019, 8:41am

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 · December 20, 2019, 3:51am

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 –

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
would you mind to guide me how to put “-no-pie” in the CFLAGS in the cling project?

Thanks a lot.
Xinghao Chen

Axel · December 20, 2019, 6:45am

I never tried cross-compilation but there are reports that it can be made to work. Patches welcome.
cling’s JIT needs fPIC (which IIRC is related to pie?) to resolve symbols.

ericxh · December 21, 2019, 2:10am

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 · December 21, 2019, 7:05am

aarch64 is working now as well.
ticket closed.

Wile_E_Coyote · December 21, 2019, 7:52am

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 · December 22, 2019, 6:42am

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 · December 22, 2019, 6:18pm

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 · December 23, 2019, 12:48am

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 · December 23, 2019, 10:38am

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

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 · December 23, 2019, 12:15pm

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

Try if you get “deterministic” behaviour with LD_PRELOAD.

ericxh · December 23, 2019, 2:34pm

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

system · January 6, 2020, 2:34pm

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.