A few questions regarding the design about unicorn-for-efi HOT 2 OPEN

Hello!

1. TianoCore EFI has its own build system, which is used to build all the drivers/apps and mold them into a "firmware image". It takes care of dealing with dependencies (e.g. Libs.. https://github.com/intel/unicorn-for-efi/blob/main/efi/UnicornEngineLib.inf#L80). While it's possible to build with Tiano headers outside of this build environment - https://github.com/vmware/esx-boot is a good example), this won't allow you to build things that depend on components built by the TianoCore build environment. And even if you built something (e.g. an ar archive), later consumption of that within the Tiano environment would be extra painful. https://github.com/intel/MultiArchUefiPkg is the current known user of unicorn-for-efi.

2. https://github.com/intel/MultiArchUefiPkg was the original motivator. Emulated x86 driver code needs to be able to call native services. But the good news is that this functionality cannot be used by MultiArchUefiPkg, because UC is not really reentrant (emulated -> native -> emulated causes corruption in the library). So, this change would not be upstreamed.

The notdirty_write fix refers to 6be64eb

3. This was just code cleanup I've done as part of trying to understand the UC code. The use of a global (hook_insert), I saw as being extra ugly so I refactored the code, producing uc_hook_add_first. See the call-site for uc_hook_add_first in uc.c. It probably doesn't need to be exported outside of the UC lib, though. It also doesn't need to be upstreamed and the cleanup was done as part of my own separate efforts around improving reentrance.

4. LTO is desired to produce smaller binaries. Small binaries are desired because MultiArchUefiPkg would get embedded in flash rom images.

from unicorn-for-efi.

Thanks for the detailed answers! I will also look into how to port these changes upstream.

from unicorn-for-efi.