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

Finally I found the culprit.

I tested also different toolchains; here the details.

On Big Sur beta 10:

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-darwin20.1.0
Thread model: posix
InstalledDir: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin

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-apple/bin

On Catalina 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
InstalledDir: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin

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-apple/bin

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
------------------------------------------------------------------------------

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 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

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 same commands reported above, give an error if:

$ make -C BaseTools/

is not run after:

$ git submodule update --init --force

All the other toolchains build files without the described issue (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 not sure where the problem is, because if you take a look at the first mac os log I attached (where I did not explicitly run $ make -C BaseTools/), BaseTools seem to have compiled:

"Finished building BaseTools C Tools with HOST_ARCH=X64"

Anyway, if I don't explicitly run:

$ make -C BaseTools/

OVMF_CODE.fd and OVMF_VARS.fd don't work properly.

Summary for tianocore logo (logo is shown: yes/no):

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


Lattner (clang was his PhD project) has always been aggressive about optimizing away undefined behavior [1]. So generally when a newer version of clang starts showing random behavior 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 behavior  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(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 = -O0 -fno-lto

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

[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


In general clang is aggressive about promoting new warning to -Wall every release 

Thanks,

Andrew Fish

Best regards

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


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


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

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

The compiler flags live in  BaseTools/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 your macOS debug log as I would expect [1]d:
"HII Image Package with logo not found in PE/COFF resource section”
I don’t see that error message in the kali log, so that matches what I would expect. 

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

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(0x2,0xFFFF,0x0) -> PciRoot(0x0)/Pci(0x1F,0x2)/Sata(0x2,0xFFFF,0x0)/HD(1,GPT,58F0B968-76EA-4F98-BD18-44DC6D57AEBA,0x800,0x7F7DF)/\EFI\BOOT\BOOTX64.EFI
Loading driver at 0x0007DDEB000 EntryPoint=0x0007DDEFE36 Bootstrap.efi
Loading driver at 0x0007DC77000 EntryPoint=0x0007DCED3A5 OpenCore.efi
Loading driver at 0x0007DDDA000 EntryPoint=0x0007DDDA5C9 AE4C11C8-1D6C-F24E-A183-E1CA36D1A8A9.efi
Loading driver at 0x0007F88E000 EntryPoint=0x0007F8920BD OpenRuntime.efi
Loading driver at 0x0007DD45000 EntryPoint=0x0007DD56C4B OpenCanopy.efi
Loading driver at 0x0007DD66000 EntryPoint=0x0007DD6FC53 AudioDxe.efi
Loading driver at 0x0007DDCE000 EntryPoint=0x0007DDD17C9 UsbMouseDxe.efi
Loading driver at 0x0007D054000 EntryPoint=0x0007D0A220C apfs.efi

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

There was some work on a CLANGPDB toolchain that worked on all platforms. 

Thanks for this, I rapidly had a look at the github page; so these commands:
$ 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=~/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

will 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 Shell?

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’m wondering what happens if you boot another guest OS. At least on OVMF if you don’t have a guest OS to boot then you drop into an UEFI Shell (EFI Application) that is built into the EFI ROM. 

Thanks,

Andrew Fish