rename-dynamic-symbols.sh fails during the compilation with "span access out of range" error

[Duraisankarp]

I am compiling the patchelf 0.18.0 for s390x and getting these failure,

Compilation failure:

[ 70s] FAIL: rename-dynamic-symbols.sh [ 70s] =============================== [ 70s] [ 70s] patching ELF file '/home/abuild/rpmbuild/BUILD/patchelf-0.18.0/tests/libmany-syms.so' [ 70s] skip renaming dynamic symbol nskip renaming dynamic symbol nrenaming dynamic symbol __cxa_finalize to __cxa_finalize_special_suffix [ 70s] renaming dynamic symbol _ITM_deregisterTMCloneTable to _ITM_deregisterTMCloneTable_special_suffix [ 70s] renaming dynamic symbol gmon_start to __gmon_start___special_suffix [ 70s] renaming dynamic symbol _ITM_registerTMCloneTable to _ITM_registerTMCloneTable_special_suffix .. .. .. [ 70s] patchelf: error: Span access out of range. [ 70s] FAIL rename-dynamic-symbols.sh (exit status: 1)

I suspect the test script for injecting out of range size. Can you have a look at it ?

[Prime541]

Hello, I have the same issue with Linux x86_64 since patchelf-0.18.0. FAIL: rename-dynamic-symbols.sh

File: tests/rename-dynamic-symbols.sh.log

patching ELF file '/tmp/tmp.NO1jJ1rhHs/patchelf-0.18.0/tests/libmany-syms.so'
skip renaming dynamic symbol nrenaming dynamic symbol _ITM_deregisterTMCloneTable to _ITM_deregisterTMCloneTable_special_suffix
renaming dynamic symbol __gmon_start__ to __gmon_start___special_suffix
[...]
./many-syms-main: Symbol `f1999_special_suffix' causes overflow in R_X86_64_PC32 relocation
./many-syms-main: Symbol `f2000_special_suffix' causes overflow in R_X86_64_PC32 relocation
./rename-dynamic-symbols.sh: line 84: 85582 Segmentation fault      (core dumped) env LD_BIND_NOW=1 LD_LIBRARY_PATH="${PWD}" ./many-syms-main
FAIL rename-dynamic-symbols.sh (exit status: 139)

/tmp/tmp.NO1jJ1rhHs/patchelf-0.18.0>(cd ./tests/scratch/rename-dynamic-symbols/env && gdb ./many-syms-main ./core.87468)
[...]
Program terminated with signal SIGSEGV, Segmentation fault.
#0  0x00005568456cb130 in ?? ()
(gdb) bt
#0  0x00005568456cb130 in ?? ()
#1  0x00005567d0e59e8b in main () at many-syms-main.c:2

uname -a
Linux HOSTNAME 4.12.14-122.162-default #1 SMP Tue Jun 6 12:25:40 UTC 2023 (02a1ae5) x86_64 x86_64 x86_64 GNU/Linux

Cause: https://github.com/NixOS/patchelf/compare/0.17.2...0.18.0 https://github.com/NixOS/patchelf/commit/0b6b66687370f2ae97310edbdbd61e7a81ac3019 https://github.com/NixOS/patchelf/pull/459

[Duraisankarp]

@brenoguim Can you have a look at this issue and help ?

[jamborm]

I see the same issue when running make check on SUSE Linux Enterprise 15 system (as opposed to openSUSE Tumbleweed). I have not really investigated the details, but what seems wrong is that many_syms_main-many-syms-main.o is compiled with -pie but without -fPIE. Fixing that issue also made the make check failure go away. Can you try if the following patch helps?

diff --git a/tests/Makefile.am b/tests/Makefile.am
index 8bbded7..49454d4 100644
--- a/tests/Makefile.am
+++ b/tests/Makefile.am
@@ -164,7 +164,7 @@ many_syms_main_SOURCES = many-syms-main.c
 many_syms_main_LDFLAGS = $(LDFLAGS_local) 
 many_syms_main_LDADD = -lmany-syms $(AM_LDADD)
 many_syms_main_DEPENDENCIES = libmany-syms.so
-many_syms_main_CFLAGS = -pie
+many_syms_main_CFLAGS = -pie -fPIE
 libmany_syms_so_SOURCES = many-syms.c
 libmany_syms_so_LDFLAGS = $(LDFLAGS_sharedlib)
 

[jamborm]

I have created a pull request https://github.com/NixOS/patchelf/pull/547 with this change.