| Message ID | 20200210043516.1996-1-christopher.w.clark@gmail.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | tools/configure: generate stubs and long-double 32-bit headers if needed | expand |
On Sun, Feb 09, 2020 at 08:35:14PM -0800, Christopher Clark wrote: > The gnu/stubs-32.h and bits/long-double-32.h headers are required to > build hvmloader but are not always available in 64-bit build > environments. To avoid introducing a build requirement on 32-bit > multilib generate versions of them from the 64-bit equivalent header. > > This patch enables the removal of downstream patching that has been > carried in the Yocto/OpenEmbedded meta-virtualization layer since 2012. > > Signed-off-by: Christopher Clark <christopher.clark6@baesystems.com> I think this would be better done in tools/include as part of populating tools/include. Also this looks specific to using gcc to build the tools, which could be skipped when building with clang? Thanks, Roger.
Christopher Clark writes ("[PATCH] tools/configure: generate stubs and long-double 32-bit headers if needed"):
> The gnu/stubs-32.h and bits/long-double-32.h headers are required to
> build hvmloader but are not always available in 64-bit build
> environments. To avoid introducing a build requirement on 32-bit
> multilib generate versions of them from the 64-bit equivalent header.
>
> This patch enables the removal of downstream patching that has been
> carried in the Yocto/OpenEmbedded meta-virtualization layer since 2012.
Thanks for this patch. However, I'm quite doubtful about the
approach.
> + echo '#include <gnu/stubs-64.h>' >conf-stubs.c
> + SIXTY_FOUR_HDR=`$CC -M conf-stubs.c | grep '/stubs-64.h$'`
> + rm conf-stubs.c
> + mkdir -p include/gnu
> + cat "${SIXTY_FOUR_HDR}" | \
> + grep -v 'stub_bdflush\|stub_getmsg\|stub_putmsg' >include/gnu/stubs-32.h
> + echo \#define __stub___kernel_cosl >> include/gnu/stubs-32.h
> + echo \#define __stub___kernel_sinl >> include/gnu/stubs-32.h
> + echo \#define __stub___kernel_tanl >> include/gnu/stubs-32.h
This code seems to be ad-hoc seddery which depends on the details of
the existing header file. That seems like it is unprincipled and
fragile, to me.
I don't understand why you wouldn't just make a small package or
tarball or something containing the relevant headers and install
that ?
Also, don't you need a 32-bit libgcc too ?
Thanks,
Ian.
On Mon, Feb 10, 2020 at 8:21 AM Ian Jackson <ian.jackson@citrix.com> wrote: > > Christopher Clark writes ("[PATCH] tools/configure: generate stubs and long-double 32-bit headers if needed"): > > The gnu/stubs-32.h and bits/long-double-32.h headers are required to > > build hvmloader but are not always available in 64-bit build > > environments. To avoid introducing a build requirement on 32-bit > > multilib generate versions of them from the 64-bit equivalent header. > > > > This patch enables the removal of downstream patching that has been > > carried in the Yocto/OpenEmbedded meta-virtualization layer since 2012. > > Thanks for this patch. However, I'm quite doubtful about the > approach. Thanks for the review and recommendation for an alternative direction. > > + echo '#include <gnu/stubs-64.h>' >conf-stubs.c > > + SIXTY_FOUR_HDR=`$CC -M conf-stubs.c | grep '/stubs-64.h$'` > > + rm conf-stubs.c > > + mkdir -p include/gnu > > + cat "${SIXTY_FOUR_HDR}" | \ > > + grep -v 'stub_bdflush\|stub_getmsg\|stub_putmsg' >include/gnu/stubs-32.h > > + echo \#define __stub___kernel_cosl >> include/gnu/stubs-32.h > > + echo \#define __stub___kernel_sinl >> include/gnu/stubs-32.h > > + echo \#define __stub___kernel_tanl >> include/gnu/stubs-32.h > > This code seems to be ad-hoc seddery which depends on the details of > the existing header file. That seems like it is unprincipled and > fragile, to me. > > I don't understand why you wouldn't just make a small package or > tarball or something containing the relevant headers and install > that ? > > Also, don't you need a 32-bit libgcc too ? OK, I've produced a revised proposal downstream that retires this header file generation altogether and applies OpenEmbedded's multilib support to make a populated 32-bit sysroot with headers and libraries available to build with. The remaining challenge is that the OE build populates and makes this 32-bit sysroot available in a different directory to the primary target architecture sysroot, so: do you have a recommendation for how to plumb an additional CFLAG into Xen's tools/firmware build? At the moment, I'm appending this single line: CFLAGS += "--sysroot=/this/is/my/sysroot32" to tools/firmware/Rules.mk but I think a dedicated top-level variable for the purpose, plumbed through, could be more appropriate? Christopher
diff --git a/tools/configure b/tools/configure index 977a8837c3..29cca6267a 100755 --- a/tools/configure +++ b/tools/configure @@ -9769,7 +9769,55 @@ else systemd=n fi +# If 32-bit stubs header is not already available, check for the 64-bit one +# and generate a 32-bit stubs header +ac_fn_c_check_header_mongrel "$LINENO" "gnu/stubs-32.h" "ac_cv_header_gnu_stubs_32_h" "$ac_includes_default" +if test "x$ac_cv_header_gnu_stubs_32_h" = xyes; then : +else + + ac_fn_c_check_header_mongrel "$LINENO" "gnu/stubs-64.h" "ac_cv_header_gnu_stubs_64_h" "$ac_includes_default" +if test "x$ac_cv_header_gnu_stubs_64_h" = xyes; then : + + echo '#include <gnu/stubs-64.h>' >conf-stubs.c + SIXTY_FOUR_HDR=`$CC -M conf-stubs.c | grep '/stubs-64.h$'` + rm conf-stubs.c + mkdir -p include/gnu + cat "${SIXTY_FOUR_HDR}" | \ + grep -v 'stub_bdflush\|stub_getmsg\|stub_putmsg' >include/gnu/stubs-32.h + echo \#define __stub___kernel_cosl >> include/gnu/stubs-32.h + echo \#define __stub___kernel_sinl >> include/gnu/stubs-32.h + echo \#define __stub___kernel_tanl >> include/gnu/stubs-32.h + +else + as_fn_error $? "" "$LINENO" 5No gnu stubs headers found +fi + + +fi + +# If 32-bit long-double header is not already available, check for the 64-bit +# one and copy it +ac_fn_c_check_header_mongrel "$LINENO" "bits/long-double-32.h" "ac_cv_header_bits_long_double_32_h" "$ac_includes_default" +if test "x$ac_cv_header_bits_long_double_32_h" = xyes; then : + +else + + ac_fn_c_check_header_mongrel "$LINENO" "bits/long-double-64.h" "ac_cv_header_bits_long_double_64_h" "$ac_includes_default" +if test "x$ac_cv_header_bits_long_double_64_h" = xyes; then : + + echo '#include <bits/long-double-64.h>' >conf-double.c + SIXTY_FOUR_HDR=`$CC -M conf-double.c | grep '/long-double-64.h$'` + rm conf-double.c + mkdir -p include/bits + cat "${SIXTY_FOUR_HDR}" >include/bits/long-double-32.h + +else + as_fn_error $? "" "$LINENO" 5No long-double headers found +fi + + +fi if test "x$systemd" = "xy"; then : diff --git a/tools/configure.ac b/tools/configure.ac index 8d86c42de8..769406e9ca 100644 --- a/tools/configure.ac +++ b/tools/configure.ac @@ -488,4 +488,28 @@ AC_ARG_ENABLE([pvshim], ]) AC_SUBST(pvshim) +# If 32-bit stubs header is not already available, check for the 64-bit one +# and generate a 32-bit stubs header +AC_CHECK_HEADER([gnu/stubs-32.h], [], [ + AC_CHECK_HEADER([gnu/stubs-64.h], [ + echo '#include <gnu/stubs-64.h>' >conf-stubs.c + SIXTY_FOUR_HDR=`$CC -M conf-stubs.c | grep '/stubs-64.h$'` + rm conf-stubs.c + mkdir -p include/gnu + cat "${SIXTY_FOUR_HDR}" | \ + grep -v 'stub_bdflush\|stub_getmsg\|stub_putmsg' >include/gnu/stubs-32.h + echo \#define __stub___kernel_cosl >> include/gnu/stubs-32.h + echo \#define __stub___kernel_sinl >> include/gnu/stubs-32.h + echo \#define __stub___kernel_tanl >> include/gnu/stubs-32.h + ], [AC_MSG_ERROR[No gnu stubs headers found]], []) ], []) + +AC_CHECK_HEADER([bits/long-double-32.h], [], [ + AC_CHECK_HEADER([bits/long-double-64.h], [ + echo '#include <bits/long-double-64.h>' >conf-double.c + SIXTY_FOUR_HDR=`$CC -M conf-double.c | grep '/long-double-64.h$'` + rm conf-double.c + mkdir -p include/bits + cat "${SIXTY_FOUR_HDR}" >include/bits/long-double-32.h + ], [AC_MSG_ERROR[No long-double headers found]], []) ], []) + AC_OUTPUT()
The gnu/stubs-32.h and bits/long-double-32.h headers are required to build hvmloader but are not always available in 64-bit build environments. To avoid introducing a build requirement on 32-bit multilib generate versions of them from the 64-bit equivalent header. This patch enables the removal of downstream patching that has been carried in the Yocto/OpenEmbedded meta-virtualization layer since 2012. Signed-off-by: Christopher Clark <christopher.clark6@baesystems.com> --- tools/configure | 48 ++++++++++++++++++++++++++++++++++++++++++++++ tools/configure.ac | 24 +++++++++++++++++++++++ 2 files changed, 72 insertions(+)