Hi Julien, > -----Original Message----- > From: Julien Grall <jul...@xen.org> > Sent: 2022年6月24日 17:50 > To: Jan Beulich <jbeul...@suse.com> > Cc: nd <n...@arm.com>; Stefano Stabellini <sstabell...@kernel.org>; Bertrand > Marquis <bertrand.marq...@arm.com>; Volodymyr Babchuk > <volodymyr_babc...@epam.com>; Andrew Cooper <andrew.coop...@citrix.com>; > Roger Pau Monné <roger....@citrix.com>; Wei Liu <w...@xen.org>; Jiamei Xie > <jiamei....@arm.com>; xen-devel@lists.xenproject.org; Wei Chen > <wei.c...@arm.com> > 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 <jbeul...@suse.com> > >>>> Sent: 2022年6月23日 20:54 > >>>> To: Wei Chen <wei.c...@arm.com> > >>>> Cc: nd <n...@arm.com>; Stefano Stabellini <sstabell...@kernel.org>; > Julien > >>>> Grall <jul...@xen.org>; Bertrand Marquis <bertrand.marq...@arm.com>; > >>>> Volodymyr Babchuk <volodymyr_babc...@epam.com>; Andrew Cooper > >>>> <andrew.coop...@citrix.com>; Roger Pau Monné <roger....@citrix.com>; > Wei > >>>> Liu <w...@xen.org>; Jiamei Xie <jiamei....@arm.com>; xen- > >>>> de...@lists.xenproject.org > >>>> 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
