On 24.06.2022 12:05, Jan Beulich wrote: > 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.
Or a note-like one (just to avoid possible confusion); I think it's ".ARM.attributes". Jan > 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 >
