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; 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. Jan
