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

[Jan Beulich <jbeulich@xxxxxxxx>]

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 <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?
> 
> 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
>