link failure: read-only segment has dynamic relocations (arch/riscv/src/vector.o)

[orlitzky]

After #66 there is another RELRO failure using GCC 14/15 on my distro:

echo "  LD      zsbl.elf"
  LD      zsbl.elf
gcc -static -nostartfiles -Wl,--cref -Wl,--gc-sections -nostdlib -g -Wl,--no-dynamic-linker -Wl,-pie -Wl,--no-warn-rwx-segments \
	-Wl,--whole-archive \
	  common/built-in.a  arch/riscv/src/built-in.a   drivers/built-in.a  lib/built-in.a  plat/built-in.a  test/built-in.a \
	 \
	-Wl,--no-whole-archive \
	-Wl,-T,arch/riscv/src/target-ram.lds \
	-Wl,-Map,zsbl.map \
	-o zsbl.elf
/usr/lib/gcc/riscv64-unknown-linux-musl/15/../../../../riscv64-unknown-linux-musl/bin/ld: arch/riscv/src/vector.o: warning: relocation against `_fw_start' in read-only section `.vector'
/usr/lib/gcc/riscv64-unknown-linux-musl/15/../../../../riscv64-unknown-linux-musl/bin/ld: read-only segment has dynamic relocations
collect2: error: ld returned 1 exit status
make[1]: *** [/home/mjo/src/zsbl.git/Makefile:780: zsbl.elf] Error 1
make: *** [../Makefile:175: sub-make] Error 2

[SophgoChaoWei]

Do you have some method, about reproduce this issue on x86 machines? with gcc 14.2?
We don't have a distribution which gcc version is greater than 13...
I compiled zsbl on openEuler 24.03 with gcc 12, it didn't appear.
And on x86 machines, with prebuilt gcc 14(download from github), and didn't reproduce again.
Maybe you can give me some instructions on how to build gcc14/15 on risc-v machines from source(ubuntu 24.04, openEuler 24.03 or maybe some other distributions)

Thanks

[orlitzky]

I don't have an x86 machine any more so I am only able to work on the Pioneer box. I think the difference between my GCC and yours may be some hardening features. I ran gcc with --verbose, and there are several options being inserted. The interesting ones are,

• -z now
• -z relro

There is a lot of documentation for our hardened compiler, and red hat does something similar:

• https://wiki.gentoo.org/wiki/Hardened/Toolchain#Default_to_marking_read-only.2C_sections_that_can_be_so_marked_after_the_loader_is_finished_.28RELRO.29
• https://www.redhat.com/en/blog/hardening-elf-binaries-using-relocation-read-only-relro

Maybe if you add those two linker flags you can reproduce it?

[dlan17]

Adding "-z now -z relro" doesn't help to reproduce this issue, but I'm using non hardened, non musl compiler
(is it likely that the relro doesn't take effect?)

riscv64-unknown-linux-gnu-gcc -static -nostartfiles -Wl,--cref -Wl,--gc-sections -Wl,-z,relro,-z,now -nostdlib -g -Wl,--no-dynamic-linker -Wl,-pie -Wl,--no-warn-rwx-segments
-Wl,--whole-archive
common/built-in.a arch/riscv/src/built-in.a drivers/built-in.a lib/built-in.a plat/built-in.a test/built-in.a

-Wl,--no-whole-archive
-Wl,-T,arch/riscv/src/target-ram.lds
-Wl,-Map,zsbl.map
-o zsbl.elf
/usr/lib/gcc/riscv64-unknown-linux-gnu/14/../../../../riscv64-unknown-linux-gnu/bin/ld: arch/riscv/src/vector.o: warning: relocation against _fw_start' in read-only section .vector'
/usr/lib/gcc/riscv64-unknown-linux-gnu/14/../../../../riscv64-unknown-linux-gnu/bin/ld: warning: creating DT_TEXTREL in a PIE
echo " CP zsbl.bin"
echo " DS zsbl.dis"
CP zsbl.bin

$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/riscv64-unknown-linux-gnu/14/lto-wrapper
Target: riscv64-unknown-linux-gnu
Configured with: /var/tmp/portage/sys-devel/gcc-14.2.1_p20241116/work/gcc-14-20241116/configure --host=riscv64-unknown-linux-gnu --build=riscv64-unknown-linux-gnu --prefix=/usr --bindir=/usr/riscv64-unknown-linux-gnu/gcc-bin/14 --includedir=/usr/lib/gcc/riscv64-unknown-linux-gnu/14/include --datadir=/usr/share/gcc-data/riscv64-unknown-linux-gnu/14 --mandir=/usr/share/gcc-data/riscv64-unknown-linux-gnu/14/man --infodir=/usr/share/gcc-data/riscv64-unknown-linux-gnu/14/info --with-gxx-include-dir=/usr/lib/gcc/riscv64-unknown-linux-gnu/14/include/g++-v14 --disable-silent-rules --disable-dependency-tracking --with-python-dir=/share/gcc-data/riscv64-unknown-linux-gnu/14/python --enable-languages=c,c++,fortran --enable-obsolete --enable-secureplt --disable-werror --with-system-zlib --enable-nls --without-included-gettext --disable-libunwind-exceptions --enable-checking=release --with-bugurl=https://bugs.gentoo.org/ --with-pkgversion='Gentoo 14.2.1_p20241116 p3' --with-gcc-major-version-only --enable-libstdcxx-time --enable-lto --disable-libstdcxx-pch --enable-shared --enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu --disable-multilib --disable-fixed-point --with-abi=lp64d --enable-libgomp --disable-libssp --disable-libada --disable-systemtap --disable-valgrind-annotations --disable-vtable-verify --disable-libvtv --without-zstd --without-isl --enable-default-pie --enable-host-pie --disable-host-bind-now --enable-default-ssp --disable-fixincludes
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 14.2.1 20241116 (Gentoo 14.2.1_p20241116 p3)

[dlan17]

how about just kill _fw_start symbol? and see if it works for you, I just check it should produce same binary..
I think it's wrong to put a symbol at .TEXT section..

https://dev.gentoo.org/~dlan/riscv/misc/zsbl-relro.patch

[orlitzky]

how about just kill _fw_start symbol? and see if it works for you, I just check it should produce same binary.. I think it's wrong to put a symbol at .TEXT section..

https://dev.gentoo.org/~dlan/riscv/misc/zsbl-relro.patch

This works, thank you. I am afraid to reboot because I don't know where my SD card is, but it builds fine now with both gcc-14 and gcc-15.

[orlitzky]

I rebooted today, no surprises. Thanks again.

[delgh1]

two weeks ago I couldn't reproduce this with gcc-14.2 (riscv64-linux-gnu-gcc) shipped from debian trixie (testing), on Pioneer. Might try again later this week since there are new commits in this repo.

Do you have some method, about reproduce this issue on x86 machines? with gcc 14.2? We don't have a distribution which gcc version is greater than 13...

@SophgoChaoWei Please do your development work on debian unstable/testing or archlinux or gentoo. Most people don't do devs on a stable distro release unless it's a backport, which is clearly not the case for zsbl.