Re: [Xen-devel] [PATCH] tools/configure: generate stubs and long-double 32-bit headers if needed

[Christopher Clark <christopher.w.clark@xxxxxxxxx>]

On Mon, Feb 10, 2020 at 8:21 AM Ian Jackson <ian.jackson@xxxxxxxxxx> 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

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel