Hi Jan, > -----Original Message----- > From: Jan Beulich <jbeul...@suse.com> > Sent: 2022年7月1日 13:54 > To: Wei Chen <wei.c...@arm.com> > Cc: nd <n...@arm.com>; Stefano Stabellini <sstabell...@kernel.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-devel@lists.xenproject.org; Julien Grall > <jul...@xen.org> > Subject: Re: [PATCH v6 1/8] xen: reuse x86 EFI stub functions for Arm > > >>>>> this way. > >>> > >>> I have taken a look into this warning: > >>> This is because the "-fshort-wchar" flag causes GCC to generate > >>> code that is not binary compatible with code generated without > >>> that flag. Why this warning hasn't been triggered in Arm64 is > >>> because we don't use any wchar in Arm64 codes. > >> > >> I don't think that's quite right - you actually say below that we > >> do use it there when interacting with UEFI. There's no warning > >> there solely because the information isn't embedded in the object > >> files there, from all I can tell. > >> > > > > Maybe I should describe it this way: Arm64 does not use wchar type > > directly in any code for parameters, variables and return values. > > So Arm64 object files are exactly the same with "-fshort-wchar" and > > without "-fshort-wchar". > > > > Although Xen's EFI code interacts with UEFI firmware, similar to RPC > > function calls, these code also do not explicitly use wchar. > > How does it not? There are ample string literals as well as enough > uses of CHAR16 (the UEFI "abstraction" of wchar_t). >
But I don't think CHAR16 will be affected by -fshort-wchar, because we have specified CHAR16 as unsigned short type in typedef. I'll try the -fno-short-wchar method from your subsequent mail, if it works, that would be the least impactful way. Cheers, Wei Chen > Jan
