From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from ma1-aaemail-dr-lapp03.apple.com (ma1-aaemail-dr-lapp03.apple.com [17.171.2.72]) by mx.groups.io with SMTP id smtpd.web11.15473.1602949160223146418 for ; Sat, 17 Oct 2020 08:39:20 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@apple.com header.s=20180706 header.b=hoRVxdwS; spf=pass (domain: apple.com, ip: 17.171.2.72, mailfrom: afish@apple.com) Received: from pps.filterd (ma1-aaemail-dr-lapp03.apple.com [127.0.0.1]) by ma1-aaemail-dr-lapp03.apple.com (8.16.0.42/8.16.0.42) with SMTP id 09HFYF18013673; Sat, 17 Oct 2020 08:39:19 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apple.com; h=from : message-id : content-type : mime-version : subject : date : in-reply-to : cc : to : references; s=20180706; bh=PWoaaYfhk2xoucslsJ2L2P413KC2xcbxnWQnfhSGoxA=; b=hoRVxdwS5RilJkLlPGs97/3LI7iDqndG9j4qAilHdhpTrq9065zFX3vnONQFa9v6Gsly SF2hRPSMvfB6jFfMegVP8hX7HmeEjOPlUczabV8KmEPb9K6hmRE4Rvn1vUfB68moFMuz Ktoggp8sH2OKS3eXQ5u4sFgP6oAuOjUHO96jzHBjcdW+hpWZGtKMas/yfGH4oOE977Dc aH1AJCQ6D7GBIPVBSVdned7crIGt33Ivn6NfWFf29kfVRWe9SeJQEwGSPVzFwrNGz5K2 TPrazNfveC/JG28foLIJF3B3T3qzY71ngIf1dn8sZgt3tX0x2C9xBMEk4/lua+M0kvFY RA== Received: from rn-mailsvcp-mta-lapp04.rno.apple.com (rn-mailsvcp-mta-lapp04.rno.apple.com [10.225.203.152]) by ma1-aaemail-dr-lapp03.apple.com with ESMTP id 347ykt3cb7-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Sat, 17 Oct 2020 08:39:19 -0700 Received: from rn-mailsvcp-mmp-lapp03.rno.apple.com (rn-mailsvcp-mmp-lapp03.rno.apple.com [17.179.253.16]) by rn-mailsvcp-mta-lapp04.rno.apple.com (Oracle Communications Messaging Server 8.1.0.6.20200729 64bit (built Jul 29 2020)) with ESMTPS id <0QIC00GNRRHIJD30@rn-mailsvcp-mta-lapp04.rno.apple.com>; Sat, 17 Oct 2020 08:39:18 -0700 (PDT) Received: from process_milters-daemon.rn-mailsvcp-mmp-lapp03.rno.apple.com by rn-mailsvcp-mmp-lapp03.rno.apple.com (Oracle Communications Messaging Server 8.1.0.6.20200729 64bit (built Jul 29 2020)) id <0QIC00100POI8L00@rn-mailsvcp-mmp-lapp03.rno.apple.com>; Sat, 17 Oct 2020 08:39:18 -0700 (PDT) X-Va-A: X-Va-T-CD: 4ddc11f9b8f5b925413972d5a8e8042b X-Va-E-CD: 0e97c8df0489df178b983445b89867ca X-Va-R-CD: 8b007e8ffd3365a77500ff05637ced77 X-Va-CD: 0 X-Va-ID: 4f9a631d-b521-46da-a704-2149ab488da7 X-V-A: X-V-T-CD: 4ddc11f9b8f5b925413972d5a8e8042b X-V-E-CD: 0e97c8df0489df178b983445b89867ca X-V-R-CD: 8b007e8ffd3365a77500ff05637ced77 X-V-CD: 0 X-V-ID: a1cc5e8f-3c72-452c-b9f5-723aea557eeb X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.235,18.0.687 definitions=2020-10-17_11:2020-10-16,2020-10-17 signatures=0 Received: from [17.235.26.241] (unknown [17.235.26.241]) by rn-mailsvcp-mmp-lapp03.rno.apple.com (Oracle Communications Messaging Server 8.1.0.6.20200729 64bit (built Jul 29 2020)) with ESMTPSA id <0QIC00KKKRHFS500@rn-mailsvcp-mmp-lapp03.rno.apple.com>; Sat, 17 Oct 2020 08:39:17 -0700 (PDT) From: "Andrew Fish" Message-id: <57786E05-5CF0-4261-9606-1F6E0FC1F42D@apple.com> MIME-version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\)) Subject: Re: [edk2-devel] Issues with edk2 compilation with xcode5 on mac OS - files compiled but strange behaviors Date: Sat, 17 Oct 2020 08:39:15 -0700 In-reply-to: Cc: edk2-devel-groups-io To: Daniele Crudo References: <1D62256C-60B6-4453-AA33-1DCF7E125DD9@apple.com> X-Mailer: Apple Mail (2.3608.120.23.2.1) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.235,18.0.687 definitions=2020-10-17_11:2020-10-16,2020-10-17 signatures=0 Content-type: multipart/alternative; boundary="Apple-Mail=_12C7E86D-8DE0-4CBB-8F8C-34350511BF08" --Apple-Mail=_12C7E86D-8DE0-4CBB-8F8C-34350511BF08 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Oct 17, 2020, at 5:19 AM, Daniele Crudo wro= te: >=20 > Finally I found the culprit. >=20 > I tested also different toolchains; here the details. >=20 > On Big Sur beta 10: >=20 > Xcode 12.0.1 > Build version 12A7300 >=20 > 1- Toolchain 1: > Apple clang version 12.0.0 (clang-1200.0.32.2) > Target: x86_64-apple-darwin20.1.0 > Thread model: posix > InstalledDir: /Applications/Xcode.app/Contents/Developer/Toolchains/Xcod= eDefault.xctoolchain/usr/bin >=20 > 2- Toolchain 2: > clang version 9.0.0 (git://github.com/llvm/llvm-project.git 0399d5a9682b3cef71c653373e38890c63c4c365) > Target: x86_64-apple-darwin20.1.0 > Thread model: posix > InstalledDir: /Users/daniele/Downloads/clang+llvm-9.0.0-x86_64-darwin-ap= ple/bin >=20 > On Catalina 10.15.7: >=20 > Xcode 12.0.1 > Build version 12A7300 >=20 > 1- Toolchain 1: > Apple clang version 12.0.0 (clang-1200.0.32.2) > Target: x86_64-apple-darwin19.6.0 > Thread model: posix > InstalledDir: /Applications/Xcode.app/Contents/Developer/Toolchains/Xcod= eDefault.xctoolchain/usr/bin >=20 > 2- Toolchain 2: > clang version 9.0.0 (git://github.com/llvm/llvm-project.git 0399d5a9682b3cef71c653373e38890c63c4c365) > Target: x86_64-apple-darwin19.6.0 > Thread model: posix > InstalledDir: /Users/daniele/Downloads/clang+llvm-9.0.0-x86_64-darwin-ap= ple/bin >=20 > 3- Toolchain 3: > Apple clang version 7.0.0 (based on LLVM 7.0.0) > Target: x86_64-apple-darwin19.6.0 > Thread model: posix > InstalledDir: /Library/Developer/Toolchains/swift-latest.xctoolchain/usr= /bin > ------------------------------------------------------------------------= ------ >=20 > I noticed that the issue was with Catalina and Toolchain 3. > Commands to compile the files with GPU issue (Toolchain 3): >=20 > $ git clone https://github.com/tianocore/edk2.git > $ cd edk2 > $ git clean -ffdx > $ git reset --hard > $ git submodule deinit --force --all > $ git checkout edk2-stable202008 > $ git submodule update --init --force > $ source edksetup.sh > $ nice make -C "$EDK_TOOLS_PATH" -j $(getconf _NPROCESSORS_ONLN) > $ build -a X64 -b RELEASE -p OvmfPkg/OvmfPkgX64.dsc -t XCODE5 >=20 > These commands build files successfully, but OVMF_VARS.fd and OVMF_CODE.= fd give the described issue (cannot boot if hdmi is not plugged in). >=20 > Other toolchains (both on Big Sur and Catalina), with the same commands = reported above, give an error if: >=20 > $ make -C BaseTools/ >=20 > is not run after: >=20 > $ git submodule update --init --force >=20 > All the other toolchains build files without the described issue (I can = boot with only dvi attached). >=20 > So, I thought, let's run: >=20 > $ make -C BaseTools/ >=20 > with toolchain 3 (clang 7, on Catalina) and boom, I'm able to boot with = only dvi attached. >=20 > I'm not sure where the problem is, because if you take a look at the fir= st mac os log I attached (where I did not explicitly run $ make -C BaseTool= s/), BaseTools seem to have compiled: >=20 > "Finished building BaseTools C Tools with HOST_ARCH=3DX64" >=20 > Anyway, if I don't explicitly run: >=20 > $ make -C BaseTools/ >=20 > OVMF_CODE.fd and OVMF_VARS.fd don't work properly. >=20 > Summary for tianocore logo (logo is shown: yes/no): >=20 > Clang 12.0: NO > Clang 9.0: YES > Clang 7.0: YES >=20 Lattner (clang was his PhD project) has always been aggressive about optim= izing away undefined behavior [1]. So generally when a newer version of cla= ng starts showing random behavior my 1st thought is the optimize has found = some new undefined behavior and optimized It away. This generally ends up w= ith hard to track down bugs :(. One tick to debug undefined behavior is to turn off optimization for a gi= ven driver or library. You can turn off optimizations by adding an entry li= ke this to the drivers=20 /Volumes/Case/edk2-github(master)>git diff diff --git a/OvmfPkg/QemuVideoDxe/QemuVideoDxe.inf b/OvmfPkg/QemuVideoDxe/= QemuVideoDxe.inf index fe8befd51d3c..e897a5da925b 100644 --- a/OvmfPkg/QemuVideoDxe/QemuVideoDxe.inf +++ b/OvmfPkg/QemuVideoDxe/QemuVideoDxe.inf @@ -64,3 +64,6 @@ [Protocols] [Pcd] gUefiOvmfPkgTokenSpaceGuid.PcdOvmfHostBridgePciDevId gEfiMdeModulePkgTokenSpaceGuid.PcdNullPointerDetectionPropertyMask + +[BuildOptions] + XCODE:*_*_*_CC_FLAGS =3D -O0 -fno-lto Then see if the issue goes away. This at leasts get you pointed in the cor= rect direction.=20 [1] https://blog.llvm.org/posts/2011-05-13-what-every-c-programmer-should-= know/ > Summary for building (can compile without errors, without explicitly run= "make -C BaseTools/": yes/no): > Clang 12.0: NO > Clang 9.0: NO > Clang 7.0: YES >=20 In general clang is aggressive about promoting new warning to -Wall every = release=20 Thanks, Andrew Fish > Best regards >=20 > Il giorno ven 16 ott 2020 alle ore 22:05 Andrew Fish > ha scritto: >=20 >=20 >> On Oct 16, 2020, at 12:24 PM, Daniele Crudo > wrote: >>=20 >>=20 >> Sorry I missed the edk2-devel in cc, resending. >>=20 >> OK so the DEBUG and RELEASE both build with -Os. This is firmware thing= s have to fit in the ROM. The big difference between DEBUG and release is t= he DEBUG prints get stripped out, so that usually means timing issues :(.= =20 >>=20 >> The compiler flags live in BaseTools/Conf/tools_def.template and you c= an edit them in Conf/tools_def.txt >>=20 >> ok, thanks for this, I was hoping in optimization issue but it seems it= 's not the case (?) >>=20 >> What logo are your talking about? I see the TianoCore logo failed in yo= ur macOS debug log as I would expect [1]d: >> "HII Image Package with logo not found in PE/COFF resource section=E2= =80=9D >> I don=E2=80=99t see that error message in the kali log, so that matches= what I would expect.=20 >>=20 >> Yes, I was referring to the tianocore logo; I was writing that in the k= ali compiled log there are additional lines relating to tftpDynamicCommand.= efi and LinuxInitrdDynamicShellCommand.efi, which are not in the mac compil= ed log. >>=20 >> It sounds like you are talking about a logo coming from your Hackintosh= EFI boot shim? Or the macOS booter? >> This is all the Hackintosh stuff that is loading.=20 >> [Bds] Expand PciRoot(0x0)/Pci(0x1F,0x2)/Sata(0x2,0xFFFF,0x0) -> PciRoot= (0x0)/Pci(0x1F,0x2)/Sata(0x2,0xFFFF,0x0)/HD(1,GPT,58F0B968-76EA-4F98-BD18-4= 4DC6D57AEBA,0x800,0x7F7DF)/\EFI\BOOT\BOOTX64.EFI >> Loading driver at 0x0007DDEB000 EntryPoint=3D0x0007DDEFE36 Bootstrap.ef= i >> Loading driver at 0x0007DC77000 EntryPoint=3D0x0007DCED3A5 OpenCore.efi >> Loading driver at 0x0007DDDA000 EntryPoint=3D0x0007DDDA5C9 AE4C11C8-1D6= C-F24E-A183-E1CA36D1A8A9.efi >> Loading driver at 0x0007F88E000 EntryPoint=3D0x0007F8920BD OpenRuntime.= efi >> Loading driver at 0x0007DD45000 EntryPoint=3D0x0007DD56C4B OpenCanopy.e= fi >> Loading driver at 0x0007DD66000 EntryPoint=3D0x0007DD6FC53 AudioDxe.efi >> Loading driver at 0x0007DDCE000 EntryPoint=3D0x0007DDD17C9 UsbMouseDxe.= efi >> Loading driver at 0x0007D054000 EntryPoint=3D0x0007D0A220C apfs.efi >>=20 >> And this is the macOS booter (1st stage OS loader, the thing Mac EFI fi= rmware loads directly)=20 >> Loading driver at 0x0007CE48000 EntryPoint=3D0x0007CE51673 boot.efi >> >> Yes, I know and this is expected behavior, I was not referring to that = logo. >>=20 >> There was some work on a CLANGPDB toolchain that worked on all platform= s.=20 >>=20 >> Thanks for this, I rapidly had a look at the github page; so these comm= ands: >> $ wget https://releases.llvm.org/9.0.0/clang+llvm-9.0.0-x86_64-darwin-a= pple.tar.xz >> $ tar -xvf clang+llvm-9.0.0-x86_64-darwin-apple.tar.xz >> $ git clone https://github.com/tianocore/edk2.git >> $ cd edk2 >> $ git clean -ffdx >> $ git reset --hard >> $ git submodule deinit --force --all >> $ git checkout edk2-stable202008 >> $ git checkout CLANGPDB >> $ git submodule update --init --force >> $ source edksetup.sh >> $ export CLANG_BIN=3D~/my/local/path/to/clang+llvm-9.0.0-x86_64-darwin-= apple/bin/ >> $ build -a X64 -b RELEASE -p OvmfPkg/OvmfPkgX64.dsc -t CLANGPDB >>=20 >> will let me install the clang 9.0 toolchain in my mac os and build edk2= with that toolchain? >>=20 >> So it sounds like you have some kind of graphics issue on a RELEASE bui= ld? What happens if on a RELEASE XCODE build you just boot to the UEFI Shel= l? >>=20 >> Maybe I misunderstood, but I cannot boot to a shell, as soon as I type = "virsh start mymv" the screen goes black (with hdmi unplugged). >>=20 >=20 > I=E2=80=99m wondering what happens if you boot another guest OS. At leas= t on OVMF if you don=E2=80=99t have a guest OS to boot then you drop into a= n UEFI Shell (EFI Application) that is built into the EFI ROM.=20 >=20 > Thanks, >=20 > Andrew Fish >=20 >>=20 >=20 --Apple-Mail=_12C7E86D-8DE0-4CBB-8F8C-34350511BF08 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On Oct 17, 2= 020, at 5:19 AM, Daniele Crudo <crudo.daniele@gmail.com> wrote:

Finally = I found the culprit.

I tested also different t= oolchains; here the details.

On Big Sur beta 1= 0:

Xcode 12.0.1
Build version 12= A7300

1- Toolchain 1:
Apple clan= g version 12.0.0 (clang-1200.0.32.2)
Target: x86_64-apple-dar= win20.1.0
Thread model: posix
InstalledDir: /Ap= plications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain= /usr/bin

2- Toolchain 2:
clang v= ersion 9.0.0 (git://github.com/llvm/llvm-project.git 0399d5a9682b3cef71c653373e3889= 0c63c4c365)
Target: x86_64-apple-darwin20.1.0
T= hread model: posix
InstalledDir: /Users/daniele/Downloads/cla= ng+llvm-9.0.0-x86_64-darwin-apple/bin

On Catal= ina 10.15.7:

Xcode 12.0.1
Build = version 12A7300

1- Toolchain 1:
= Apple clang version 12.0.0 (clang-1200.0.32.2)
Target: x86_64= -apple-darwin19.6.0
Thread model: posix
Install= edDir: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.x= ctoolchain/usr/bin

2- Toolchain 2:
clang version 9.0.0 (git://github.com/llvm/llvm-project.git 0399d5a9682b3cef71c6= 53373e38890c63c4c365)
Target: x86_64-apple-darwin19.6.0
Thread model: posix
InstalledDir: /Users/daniele/Dow= nloads/clang+llvm-9.0.0-x86_64-darwin-apple/bin

3- Toolchain 3:
Apple clang version 7.0.0  (based on L= LVM 7.0.0)
Target: x86_64-apple-darwin19.6.0
Th= read model: posix
InstalledDir: /Library/Developer/Toolchains= /swift-latest.xctoolchain/usr/bin
---------------------------= ---------------------------------------------------

I noticed that the issue was with Catalina and Toolchain 3.
Commands to compile the files with GPU issue (Toolchain 3):

$ git clone https://github.com/tianocore/edk2.git
$ cd edk2
$ git clean -ffdx
$ git reset --hard=
$ git submodule deinit --force --all
$ git che= ckout edk2-stable202008
$ git submodule update --init --force=
$ source edksetup.sh
$ nice make -C "$EDK_TOOL= S_PATH" -j $(getconf _NPROCESSORS_ONLN)
$ build -a X64 -b REL= EASE -p OvmfPkg/OvmfPkgX64.dsc -t XCODE5

These= commands build files successfully, but OVMF_VARS.fd and OVMF_CODE.fd give = the described issue (cannot boot if hdmi is not plugged in).
=
Other toolchains (both on Big Sur and Catalina), with the sa= me commands reported above, give an error if:

= $ make -C BaseTools/

is not run after:

$ git submodule update --init --force
<= br class=3D"">All the other toolchains build files without the described is= sue (I can boot with only dvi attached).

So, I= thought, let's run:

$ make -C BaseTools/

with toolchain 3 (clang 7, on Catalina) and boom, = I'm able to boot with only dvi attached.

I'm n= ot sure where the problem is, because if you take a look at the first mac o= s log I attached (where I did not explicitly run $ make -C BaseTools/), Bas= eTools seem to have compiled:

"Finished buildi= ng BaseTools C Tools with HOST_ARCH=3DX64"

Any= way, if I don't explicitly run:

$ make -C Base= Tools/

OVMF_CODE.fd and OVMF_VARS.fd don't wor= k properly.

Summary for tianocore logo (logo i= s shown: yes/no):

Clang 12.0: NO
Clang 9.0: YES
Clang 7.0: YES


Lattner (clang was his PhD pro= ject) has always been aggressive about optimizing away undefined behavior [= 1]. So generally when a newer version of clang starts showing random behavi= or my 1st thought is the optimize has found some new undefined behavior and= optimized It away. This generally ends up with hard to track down bugs :(.=  

One tick to debug undefined beh= avior  is to turn off optimization for a given driver or library. You = can turn off optimizations by adding an entry like this to the drivers = ;

/Volumes/Case/edk2-github(ma= ster)>git diff
diff --git a/OvmfPkg/QemuVid= eoDxe/QemuVideoDxe.inf b/OvmfPkg/QemuVideoDxe/QemuVideoDxe.inf
index fe8befd51d3= c..e897a5da925b 100644
--- a/OvmfPkg/QemuVideoDxe/QemuVideoDxe.inf=
+++ b/OvmfPkg/Q= emuVideoDxe/QemuVideoDxe.inf
@@ -64,3 +64,6 @@ [P= rotocols]
 [Pcd]
   gUefiOvmfPk= gTokenSpaceGuid.PcdOvmfHostBridgePciDevId
   gEfiMdeModulePkgTokenSpaceGuid.PcdNullPoint= erDetectionPropertyMask
+
+[BuildOptions]
+  XCODE:*_*_*_CC_FLAG= S =3D -O0 -fno-lto

Then see if the issue goes away. This at leasts get you pointed in t= he correct direction. 

[1] https://blog.llvm.org/posts/2011-05-13-what-every-c-p= rogrammer-should-know/

Summar= y for building (can compile without errors, without explicitly run "make -C= BaseTools/": yes/no):
Clang 12.0: NO<= /div>
Clang 9.0: NO
Clang 7.0: YES

<= br class=3D"">
In general clang is aggressive about promoting new= warning to -Wall every release 

T= hanks,

Andrew Fish

=
Best regards

Il giorno ven 16 ott 20= 20 alle ore 22:05 Andrew Fish <afish@apple.com> ha scritto:


On Oct 16, 2020, at 12:24 PM, Danie= le Crudo <crudo.daniele@gmail.com> wrote:


Sorry I missed the edk2-devel in cc, resending.

OK so the DEBUG and RELEASE both build with -O= s. This is firmware things have to fit in the ROM. The big difference betwe= en DEBUG and release is the DEBUG prints get stripped out, so that usually = means timing issues :(. 

The compiler flags live in  BaseTool= s/Conf/tools_def.template and you can edit them in Conf/tools_def.txt
=

ok,= thanks for this, I was hoping in optimization issue but it seems it's not = the case (?)

What logo are your talking about? I see the TianoCore logo failed in you= r macOS debug log as I would expect [1]d:
"HII Image Package with logo not found in PE/COFF resource section= =E2=80=9D
I don=E2=80=99t see that error message in t= he kali log, so that matches what I would expect. 

Yes, = I was referring to the tianocore logo; I was writing that in the kali compi= led log there are additional lines relating to tftpDynamicCommand.efi = and LinuxInitrdDynamicShellCommand.efi, which are not in the mac compiled l= og.

It sounds like you are talking about a logo= coming from your Hackintosh EFI boot shim? Or the macOS booter?
This is all the Hackintosh stuff that is loading. 
[Bds] Expand PciRoot(0x0)/Pci(0x1F,0x2)/Sata(0= x2,0xFFFF,0x0) -> PciRoot(0x0)/Pci(0x1F,0x2)/Sata(0x2,0xFFFF,0x0)/HD(1,G= PT,58F0B968-76EA-4F98-BD18-44DC6D57AEBA,0x800,0x7F7DF)/\EFI\BOOT\BOOTX64.EF= I
Loading driver at 0x= 0007DDEB000 EntryPoint=3D0x0007DDEFE36 Bootstrap.efi
L= oading driver at 0x0007DC77000 EntryPoint=3D0x0007DCED3A5 OpenCore.efi
Loading driver at 0x0007DDDA000 EntryPoint=3D0x0007DDDA5C9= AE4C11C8-1D6C-F24E-A183-E1CA36D1A8A9.efi
Loading driv= er at 0x0007F88E000 EntryPoint=3D0x0007F8920BD OpenRuntime.efi
Loading driver at 0x0007DD45000 EntryPoint=3D0x0007DD56C4B OpenCan= opy.efi
Loading driver at 0x0007DD66000 EntryPoint=3D0= x0007DD6FC53 AudioDxe.efi
Loading driver at 0x0007DDCE= 000 EntryPoint=3D0x0007DDD17C9 UsbMouseDxe.efi
Loading= driver at 0x0007D054000 EntryPoint=3D0x0007D0A220C apfs.efi

And this is the mac= OS booter (1st stage OS loader, the thing Mac EFI firmware loads directly)&= nbsp;
Loading driver at 0x0007CE48000 = EntryPoint=3D0x0007CE51673 boot.efi
 
Yes, I know and this i= s expected behavior, I was not referring to that logo.

There was some work on a CLANG= PDB toolchain that worked on all platforms. 

Thanks for this, = I rapidly had a look at the github page; so these commands:
$ wget https://releases.ll= vm.org/9.0.0/clang+llvm-9.0.0-x86_64-darwin-apple.tar.xz
= $ tar -xvf clang+llvm-9.0.0-x86_64-darwin-apple.tar.xz
$ = ;git clone https://github.com/tiano= core/edk2.git
$ cd edk2
$ git= clean -ffdx
$ git reset --hard
$ git submodule= deinit --force --all
$ git checkout edk2-stable202008
$ git checkout CLANGPDB
$ git submodule update= --init --force
$ source edksetup.sh
$ export C= LANG_BIN=3D~/my/local/path/to/clang+llvm-9.0.0-x86_64-darwin-apple/bin/
$ build -a X64 -b RELEASE -p OvmfPkg/OvmfPkgX64.dsc -t CLANGPDB<= br class=3D"">

wi= ll let me install the clang 9.0 toolchain in my mac os and build edk2 with = that toolchain?

So it sounds like you have some kind of graphics issue on a RELEASE = build? What happens if on a RELEASE XCODE build you just boot to the UEFI S= hell?

Maybe I misunderstood, but I cannot boot to a shell, as soon = as I type "virsh start mymv" the screen goes black (with hdmi unplugged).


I=E2=80=99m w= ondering what happens if you boot another guest OS. At least on OVMF if you= don=E2=80=99t have a guest OS to boot then you drop into an UEFI Shell (EF= I Application) that is built into the EFI ROM. 
<= br class=3D"">
Thanks,

Andrew Fish



--Apple-Mail=_12C7E86D-8DE0-4CBB-8F8C-34350511BF08--