Hi Jan, > -----Original Message----- > From: Jan Beulich <[email protected]> > Sent: 2022年7月1日 13:54 > To: Wei Chen <[email protected]> > Cc: nd <[email protected]>; Stefano Stabellini <[email protected]>; Bertrand > Marquis <[email protected]>; Volodymyr Babchuk > <[email protected]>; Andrew Cooper <[email protected]>; > Roger Pau Monné <[email protected]>; Wei Liu <[email protected]>; Jiamei Xie > <[email protected]>; [email protected]; Julien Grall > <[email protected]> > 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
