On 12/02/16 05:36, Gao, Liming wrote: > I agree to root cause this issue with GCC6. Could you help submit this issue > in bugzilia? Then, we will investigate it further.
Thanks, Liming, I've now filed <https://bugzilla.tianocore.org/show_bug.cgi?id=281>. Cheers Laszlo > Thanks > Liming > -----Original Message----- > From: edk2-devel [mailto:[email protected]] On Behalf Of Laszlo > Ersek > Sent: Friday, December 02, 2016 2:43 AM > To: Anthony PERARD <[email protected]>; Justen, Jordan L > <[email protected]>; Gao, Liming <[email protected]>; Zhu, > Yonghong <[email protected]>; Ard Biesheuvel <[email protected]> > Cc: [email protected] > Subject: Re: [edk2] [PATCH 0/4] Fix runtime issue in XenBusDxe when compiled > with GCC5 > > On 12/01/16 16:28, Anthony PERARD wrote: >> Hi, >> >> That might be only with the Xen part of OVMF but now that the GCC5 >> toolchains is used with my gcc (6.2.1 20160830, Arch Linux), OVMF fail >> to boot in Xen guests. >> >> Here is the result: >> !!!! X64 Exception Type - 06(#UD - Invalid Opcode) CPU Apic ID - 00000000 >> !!!! >> RIP - 000000001F26AF6B, CS - 0000000000000038, RFLAGS - >> 0000000000010202 RAX - 0000000000000001, RCX - 000000001F26AF51, RDX >> - 0000000000000004 RBX - 0000000000000000, RSP - 000000001F43C510, >> RBP - 000000001E583D18 RSI - 0000000000000003, RDI - 0000000000000001 >> R8 - 0000000000000000, R9 - 0000000000000000, R10 - 000000001E58DB98 >> R11 - 0000000000000002, R12 - 000000001E58D898, R13 - >> 0000000000000000 >> R14 - 000000001E58D8A0, R15 - 000000001F26D001 >> DS - 0000000000000030, ES - 0000000000000030, FS - 0000000000000030 >> GS - 0000000000000030, SS - 0000000000000030 >> CR0 - 0000000080000033, CR2 - 0000000000000000, CR3 - >> 000000001F3DB000 >> CR4 - 0000000000000668, CR8 - 0000000000000000 >> DR0 - 0000000000000000, DR1 - 0000000000000000, DR2 - >> 0000000000000000 >> DR3 - 0000000000000000, DR6 - 00000000FFFF0FF0, DR7 - >> 0000000000000400 GDTR - 000000001F3C9A98 0000000000000047, LDTR - >> 0000000000000000 >> IDTR - 000000001EB0A018 0000000000000FFF, TR - 0000000000000000 >> FXSAVE_STATE - 000000001F43C170 >> !!!! Find PE image >> ./Build/OvmfX64/DEBUG_GCC5/X64/OvmfPkg/XenBusDxe/XenBusDxe/DEBUG/XenBusDxe.dll >> (ImageBase=000000001F266000, EntryPoint=000000001F2669D5) !!!! >> >> Removing the gcc option -flto in only the XenBusDxe module makes OVMF >> boot. >> >> While trying to debug that, I've added some debug prints (in this >> module and in XenPvBlkDxe), and the exception could change and become >> a "page fault" instead, or even an assert failure in the PrintLib, >> that was the ASSERT(Buffer != NULL) at I think >> MdePkg/Library/BasePrintLib/PrintLibInternal.c:366 >> >> Adding EFIAPI to internal functions in XenBusDxe makes things work >> again. My guest is that gcc would bypass (optimise) an exported >> functions and call directly an internal one but without reordering the >> arguments (EFIAPI vs nothing). >> >> Does that make sense? > > Thank you for the investigation. It is strange that only the Xen modules are > affected, I'm unsure what that's the case. > > Either way, it seems to be a gcc-6 bug, or an edk2 toolchain bug. You should > *not* need EFIAPI for functions with external linkage if the calls to them > straddle only files in the same module. I'm suspecting > gcc-6 (we've received no such reports with gcc-5). Maybe we need a GCC6 > toolchain as well, for turning off some new features in gcc-6? > > Jordan, Liming, Yonghong, Ard -- any ideas? > > Anthony: while we all figure this out, please consider building OVMF with the > "-b NOOPT" switch. Support for the NOOPT build target has recently been added > to the GCC Ia32/X64 toolchains in BaseTools, and to the OVMF DSC files as > well. The build targets correspond to: > > RELEASE -- compiler optimization enabled; DEBUG, ASSERT, and similar > DebugLib features compiled out > DEBUG -- compiler optimization enabled; DebugLib features preserved > NOOPT -- compiler optimization disabled; DebugLib features preserved > > (Note that for ArmVirtPkg and the GCC AARCH64 toolchains in BaseTools, there > is no NOOPT, and DEBUG means actually NOOPT -- if I remember correctly. Ard > will correct me if I'm wrong :)) > > If "-b NOOPT" works for you, I'd prefer that as a temporary solution (until > the root cause is found and addressed) to the XenBusDxe patches. > > Hrpmf, wait a second, I do see something interesting: in this series you > *are* modifying APIs declared in a library class header (namely > "OvmfPkg/Include/Library/XenHypercallLib.h"). Such functions (public > libraries) *are* required to specify EFIAPI. > > What happens if you apply patch #1 only? > > Thanks! > Laszlo > >> Anthony PERARD (4): >> OvmfPkg/XenHypercallLib: Add EFIAPI >> OvmfPkg/XenBusDxe: Add EFIAPI to XenEventChannelNotify >> OvmfPkg/XenBusDxe: Add EFIAPI to XenStore functions >> OvmfPkg/XenBusDxe: Add EFIAPI to XenGrantTable{Grant,End}Access >> >> OvmfPkg/Include/Library/XenHypercallLib.h | 3 +++ >> OvmfPkg/Library/XenHypercallLib/XenHypercall.c | 3 +++ >> OvmfPkg/XenBusDxe/EventChannel.c | 1 + >> OvmfPkg/XenBusDxe/EventChannel.h | 1 + >> OvmfPkg/XenBusDxe/GrantTable.c | 2 ++ >> OvmfPkg/XenBusDxe/XenStore.c | 13 +++++++++++++ >> OvmfPkg/XenBusDxe/XenStore.h | 10 ++++++++++ >> 7 files changed, 33 insertions(+) >> > > _______________________________________________ > edk2-devel mailing list > [email protected] > https://lists.01.org/mailman/listinfo/edk2-devel > _______________________________________________ edk2-devel mailing list [email protected] https://lists.01.org/mailman/listinfo/edk2-devel
