[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] RE: [PATCH v6 1/8] xen: reuse x86 EFI stub functions for Arm
Hi Julien, > -----Original Message----- > From: Julien Grall <julien@xxxxxxx> > Sent: 2022年6月24日 17:50 > To: Jan Beulich <jbeulich@xxxxxxxx> > Cc: nd <nd@xxxxxxx>; Stefano Stabellini <sstabellini@xxxxxxxxxx>; 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; Wei Chen > <Wei.Chen@xxxxxxx> > 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 <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? 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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |