Message ID | 20240811-microblaze-v1-1-2781ba343e75@gmx.net |
---|---|
State | Not Applicable |
Headers | show |
Series | [lvm2] acinclude.m4: Link when trying CCFLAGS | expand |
On Sun, Aug 11, 2024 at 05:52:29PM -0400, Rich Felker wrote: > On Sun, Aug 11, 2024 at 11:04:38AM +0200, J. Neuschäfer wrote: > > Through a build failure of LVM2 on musl-libc 1.2.5 in the Buildroot > > autobuild service[1], I noticed that musl-libc's Scrt1 for microblaze > > produces a relocation targeting the .text section, which subsequently > > leads to a crash at run-time because musl-libc does not support > > textrels[2]. Buildroot uses the "-z text" linker option to catch > > textrels early, on musl-libc. > > > > The error can be reduced to the following test case: > > > > $ cat hello.c > > #include <stdio.h> > > int main(void) { puts("Hello world!"); return 0; } > > $ host/bin/microblaze-buildroot-linux-musl-gcc hello.c -z text -pie -fPIC > > microblaze-buildroot-linux-musl/bin/ld: microblaze-buildroot-linux-musl/sysroot/lib/Scrt1.o: > > warning: relocation against `_start_c' in read-only section `.text' > > microblaze-buildroot-linux-musl/bin/ld: read-only segment has dynamic relocations > > collect2: error: ld returned 1 exit status [...] > > No objection, but this is a bug in the tooling (ld) that we could also > avoid on the musl side. So there are probably 3 places things should > be changed here. > > Rich I finally got around to testing your musl patch (http://0x0.st/XWB9.diff - "use hidden visibility for C entry point function _start_c"). It solves the immediate problem for microblaze(el) as far as I can see. I'm not familiar enough with linker intricacies to write a binutils/ld bug report though. -- jn
diff --git a/acinclude.m4 b/acinclude.m4 index 47fdd59c3..9b1d3a605 100644 --- a/acinclude.m4 +++ b/acinclude.m4 @@ -25,7 +25,7 @@ AC_DEFUN([AC_TRY_CCFLAG], ac_save_CFLAGS=$CFLAGS CFLAGS=$1 AC_CACHE_CHECK([whether $CC accepts $1 flag], [ac_cv_flag_$2], - [AC_COMPILE_IFELSE([AC_LANG_PROGRAM()], + [AC_LINK_IFELSE([AC_LANG_PROGRAM()], [AS_VAR_SET([ac_cv_flag_$2], [yes])], [AS_VAR_SET([ac_cv_flag_$2], [no])])]) CFLAGS=$ac_save_CFLAGS
Through a build failure of LVM2 on musl-libc 1.2.5 in the Buildroot autobuild service[1], I noticed that musl-libc's Scrt1 for microblaze produces a relocation targeting the .text section, which subsequently leads to a crash at run-time because musl-libc does not support textrels[2]. Buildroot uses the "-z text" linker option to catch textrels early, on musl-libc. The error can be reduced to the following test case: $ cat hello.c #include <stdio.h> int main(void) { puts("Hello world!"); return 0; } $ host/bin/microblaze-buildroot-linux-musl-gcc hello.c -z text -pie -fPIC microblaze-buildroot-linux-musl/bin/ld: microblaze-buildroot-linux-musl/sysroot/lib/Scrt1.o: warning: relocation against `_start_c' in read-only section `.text' microblaze-buildroot-linux-musl/bin/ld: read-only segment has dynamic relocations collect2: error: ld returned 1 exit status LVM2 uses -pie only after the AC_TRY_CCFLAG macro has determined that it can be used. This is where the problem begins: AC_TRY_CCFLAG only tries compiling, it does not try linking the resulting object file. To catch problems like this, this patch changes AC_TRY_CCFLAG to link in addition to compiling. By detecting correctly that -pie does not work on musl-libc/microblaze with -ztext, the build failure in Buildroot is fixed. [1]: http://autobuild.buildroot.net/results/dc4/dc4fc33eaeafe5d6707d26a373560402533954f6/build-end.log [2]: https://www.openwall.com/lists/musl/2020/09/25/4 Signed-off-by: J. Neuschäfer <j.neuschaefer@gmx.net> --- Hi, I'm cross-posting this to the LVM2, Buildroot, and musl mailing lists to get potential feedback early on. --- acinclude.m4 | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- base-commit: 90a845a7087478a7cdc7a60d89d2e7ee1366160e change-id: 20240811-microblaze-8ff8a6217471 Best regards, -- J. Neuschäfer <j.neuschaefer@gmx.net>