On 24.06.2022 11:49, Julien Grall wrote: > 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?
Arm32 embeds ABI information in a note section in each object file. The mismatch of the wchar_t part of this information is what causes ld to emit the 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. > > I agree. If we need a workaround, then my preference would be to not > build stub.c with -fshort-wchar. This would need to be an Arm-special then, as on x86 it needs to be built this way. Jan
