mailing list of musl libc
 help / color / mirror / code / Atom feed
* [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).