sysutils/edk2: Use clang to build

[aokblast]

Summary

edk2 supports to build with clang now. As we ship clang in our base, it
makes sense to build our edk2 binary by using clang.

Test Plan

This has been tested with building bhyve flavor and run a bhyve vm with the output binary.
Also, I have tested to build a rpi4 binary but don't have a way to test whether it works.

[michaelo]

Yeah, finally! I tried myself recently and assumed it only to be CLANG, didn' think about the dwarfs at all.
Did you compare the resuting output files, are thy binary identical?

[michaelo]

Don't forget to bump the port revision.

[aokblast]

In D57357#1314094, @michaelo wrote:

Yeah, finally! I tried myself recently and assumed it only to be CLANG, didn' think about the dwarfs at all.
Did you compare the resuting output files, are thy binary identical?

I think it is impossible for the to have same output as they have different way to generate and optimize the code.

[aokblast]

Bump port version

[aokblast]

In D57357#1314098, @michaelo wrote:

Don't forget to bump the port revision.

Thanks! Fix it right now.

[aokblast]

In D57357#1314094, @michaelo wrote:

Yeah, finally! I tried myself recently and assumed it only to be CLANG, didn' think about the dwarfs at all.
Did you compare the resuting output files, are thy binary identical?

Clang can output DWARF (for most unix world) and PDB (for windows). That is the reason why they have CLANGDWARF.

[michaelo]

In D57357#1314101, @aokblast wrote:

In D57357#1314094, @michaelo wrote:

Yeah, finally! I tried myself recently and assumed it only to be CLANG, didn' think about the dwarfs at all.
Did you compare the resuting output files, are thy binary identical?

I think it is impossible for the to have same output as they have different way to generate and optimize the code.

I agree with you. I still wonder whether a uefi-firmware-parser could reveal any logical changes.

[michaelo]

clang94 KBDownload

gcc95 KBDownload

For reference, here are the UEFI firmware parser dumps of both produces. Slight differences, I have no clue wether they are relevant.

[aokblast]

In D57357#1314112, @michaelo wrote:

clang94 KBDownload

gcc95 KBDownload

For reference, here are the UEFI firmware parser dumps of both produces. Slight differences, I have no clue wether they are relevant.

There are two main differences:

1. section size different
2. padding does not exist on clang

I don't think it creates any problem if we sucessfully to run on bhyve. rpi might need more test as arm usually have some limitations like some platform does not support non-aligned memory access.

[markmi_dsl-only.net]

So far as I know, EDK2 for the RPi4B family still has an error that prevents its use for FreeBSD --because FreeBSD detects the error and panics based on the detection.

See: https://lists.freebsd.org/archives/freebsd-arm/2024-February/003699.html

Note: the Discord "rpi4-uefi-dev" no longer exists to reference.

Added for reference for where the _CRS issue in question lives:

https://github.com/tianocore/edk2-platforms/blob/master/Platform/RaspberryPi/AcpiTables/Xhci.asl

The issue is the publishing of device space addresses for what should be arm address space addresses. FreeBSD does what is is told and ends up with two reserved address ranges in arm address space that overlap --which is what it detects and panics for.

(In earlier times, FreeBSD had made no attempt to detect such overlaps. That is part of how it took so many years to discover the EDK2 implementation error.)