RE: [PATCH v6 1/8] xen: reuse x86 EFI stub functions for Arm

[Wei Chen <Wei.Chen@xxxxxxx>]

Hi Julien,

> -----Original Message-----
> From: Julien Grall <julien@xxxxxxx>
> Sent: 2022年6月24日 17:50
> To: Jan Beulich <jbeulich@xxxxxxxx>
> Cc: nd <nd@xxxxxxx>; Stefano Stabellini <sstabellini@xxxxxxxxxx>; Bertrand
> Marquis <Bertrand.Marquis@xxxxxxx>; Volodymyr Babchuk
> <Volodymyr_Babchuk@xxxxxxxx>; Andrew Cooper <andrew.cooper3@xxxxxxxxxx>;
> Roger Pau Monné <roger.pau@xxxxxxxxxx>; Wei Liu <wl@xxxxxxx>; Jiamei Xie
> <Jiamei.Xie@xxxxxxx>; xen-devel@xxxxxxxxxxxxxxxxxxxx; Wei Chen
> <Wei.Chen@xxxxxxx>
> Subject: Re: [PATCH v6 1/8] xen: reuse x86 EFI stub functions for Arm
> 
> Hi Jan,
> 
> On 24/06/2022 10:33, Jan Beulich wrote:
> > On 24.06.2022 10:35, Julien Grall wrote:
> >> On 24/06/2022 08:18, Wei Chen wrote:
> >>>> -----Original Message-----
> >>>> From: Jan Beulich <jbeulich@xxxxxxxx>
> >>>> Sent: 2022年6月23日 20:54
> >>>> To: Wei Chen <Wei.Chen@xxxxxxx>
> >>>> Cc: nd <nd@xxxxxxx>; Stefano Stabellini <sstabellini@xxxxxxxxxx>;
> Julien
> >>>> Grall <julien@xxxxxxx>; Bertrand Marquis <Bertrand.Marquis@xxxxxxx>;
> >>>> Volodymyr Babchuk <Volodymyr_Babchuk@xxxxxxxx>; Andrew Cooper
> >>>> <andrew.cooper3@xxxxxxxxxx>; Roger Pau Monné <roger.pau@xxxxxxxxxx>;
> Wei
> >>>> Liu <wl@xxxxxxx>; Jiamei Xie <Jiamei.Xie@xxxxxxx>; xen-
> >>>> devel@xxxxxxxxxxxxxxxxxxxx
> >>>> Subject: Re: [PATCH v6 1/8] xen: reuse x86 EFI stub functions for Arm
> >>>>
> >>>> On 10.06.2022 07:53, Wei Chen wrote:
> >>>>> --- a/xen/arch/arm/Makefile
> >>>>> +++ b/xen/arch/arm/Makefile
> >>>>> @@ -1,6 +1,5 @@
> >>>>>    obj-$(CONFIG_ARM_32) += arm32/
> >>>>>    obj-$(CONFIG_ARM_64) += arm64/
> >>>>> -obj-$(CONFIG_ARM_64) += efi/
> >>>>>    obj-$(CONFIG_ACPI) += acpi/
> >>>>>    obj-$(CONFIG_HAS_PCI) += pci/
> >>>>>    ifneq ($(CONFIG_NO_PLAT),y)
> >>>>> @@ -20,6 +19,7 @@ obj-y += domain.o
> >>>>>    obj-y += domain_build.init.o
> >>>>>    obj-y += domctl.o
> >>>>>    obj-$(CONFIG_EARLY_PRINTK) += early_printk.o
> >>>>> +obj-y += efi/
> >>>>>    obj-y += gic.o
> >>>>>    obj-y += gic-v2.o
> >>>>>    obj-$(CONFIG_GICV3) += gic-v3.o
> >>>>> --- a/xen/arch/arm/efi/Makefile
> >>>>> +++ b/xen/arch/arm/efi/Makefile
> >>>>> @@ -1,4 +1,12 @@
> >>>>>    include $(srctree)/common/efi/efi-common.mk
> >>>>>
> >>>>> +ifeq ($(CONFIG_ARM_EFI),y)
> >>>>>    obj-y += $(EFIOBJ-y)
> >>>>>    obj-$(CONFIG_ACPI) +=  efi-dom0.init.o
> >>>>> +else
> >>>>> +# Add stub.o to EFIOBJ-y to re-use the clean-files in
> >>>>> +# efi-common.mk. Otherwise the link of stub.c in arm/efi
> >>>>> +# will not be cleaned in "make clean".
> >>>>> +EFIOBJ-y += stub.o
> >>>>> +obj-y += stub.o
> >>>>> +endif
> >>>>
> >>>> This has caused
> >>>>
> >>>> ld: warning: arch/arm/efi/built_in.o uses 2-byte wchar_t yet the
> output is
> >>>> to use 4-byte wchar_t; use of wchar_t values across objects may fail
> >>>>
> >>>> for the 32-bit Arm build that I keep doing every once in a while,
> with
> >>>> (if it matters) GNU ld 2.38. I guess you will want to consider
> building
> >>>> all of Xen with -fshort-wchar, or to avoid building stub.c with that
> >>>> option.
> >>>>
> >>>
> >>> Thanks for pointing this out. I will try to use -fshort-wchar for
> Arm32,
> >>> if Arm maintainers agree.
> >>
> >> Looking at the code we don't seem to build Xen arm64 with -fshort-wchar
> >> (aside the EFI files). So it is not entirely clear why we would want to
> >> use -fshort-wchar for arm32.
> >
> > We don't use wchar_t outside of EFI code afaict. Hence to all other code
> > it should be benign whether -fshort-wchar is in use. So the suggestion
> > to use the flag unilaterally on Arm32 is really just to silence the ld
> > warning;
> 
> Ok. This is odd. Why would ld warn on arm32 but not other arch? Wei, do
> you think you can have a look?
> 

Jan has already given some answers. I'll have a look and see if there's
a better way.

Cheers,
Wei Chen

> > off the top of my head I can't see anything wrong with using
> > the option also for Arm64 or even globally. Yet otoh we typically try to
> > not make changes for environments where they aren't really needed.
> 
> I agree. If we need a workaround, then my preference would be to not
> build stub.c with -fshort-wchar.
> 
> Cheers,
> 
> --
> Julien Grall