* [musl] [PATCH lvm2] acinclude.m4: Link when trying CCFLAGS
@ 2024-08-11 9:04 J. Neuschäfer
2024-08-11 21:52 ` Rich Felker
0 siblings, 1 reply; 3+ messages in thread
From: J. Neuschäfer @ 2024-08-11 9:04 UTC (permalink / raw)
To: lvm-devel; +Cc: buildroot, musl, J. Neuschäfer
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(-)
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
---
base-commit: 90a845a7087478a7cdc7a60d89d2e7ee1366160e
change-id: 20240811-microblaze-8ff8a6217471
Best regards,
--
J. Neuschäfer <j.neuschaefer@gmx.net>
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [musl] [PATCH lvm2] acinclude.m4: Link when trying CCFLAGS
2024-08-11 9:04 [musl] [PATCH lvm2] acinclude.m4: Link when trying CCFLAGS J. Neuschäfer
@ 2024-08-11 21:52 ` Rich Felker
2024-08-23 22:15 ` J. Neuschäfer
0 siblings, 1 reply; 3+ messages in thread
From: Rich Felker @ 2024-08-11 21:52 UTC (permalink / raw)
To: J. Neuschäfer; +Cc: lvm-devel, buildroot, musl
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
>
> 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(-)
>
> 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
>
> ---
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
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [musl] [PATCH lvm2] acinclude.m4: Link when trying CCFLAGS
2024-08-11 21:52 ` Rich Felker
@ 2024-08-23 22:15 ` J. Neuschäfer
0 siblings, 0 replies; 3+ messages in thread
From: J. Neuschäfer @ 2024-08-23 22:15 UTC (permalink / raw)
To: Rich Felker; +Cc: J. Neuschäfer, lvm-devel, buildroot, musl
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
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2024-08-23 22:15 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2024-08-11 9:04 [musl] [PATCH lvm2] acinclude.m4: Link when trying CCFLAGS J. Neuschäfer
2024-08-11 21:52 ` Rich Felker
2024-08-23 22:15 ` J. Neuschäfer
Code repositories for project(s) associated with this public inbox
https://git.vuxu.org/mirror/musl/
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).