OSDev.org

Since the interface of EDK2 is so strange and troublesome...
Is there a way to link .obj files directly to .efi,
or is there a way to convert a particularly designed .dll or .exe into .efi ?

I know FASM can generate EFI images in a sample way, but can't find a "-S" option for cl

I guess a EFI image has little difference with a DLL image, for they're all PE format and x64 native code,
so maybe a manually modification can be a solution ?

BTW, Is there sth. really in EFI Byte Code ?

As always in programming, there's not the single one best answer. What I prefer is creating my own library and compiling it as an ELF. You can use objcopy to get the proper UEFI format. I tested this once and it worked flawlessly.

I have no idea about Windows tools, but as always, having a Linux box will help you dramatically.

I like this method. Which configure parameters (target triplet?) did you use when compiling objcopy / binutils, and with which parameters do you use it for the conversion to uefi?

Yes, EDK2 is a horrible example of how not to do things, using a proper PE-oriented toolchain is certainly the better alternative. In particular:EDK2 on linux does exactly that, and it results in defective binaries.

Since you seem to be using Visual Studio, you're probably interested in it's /SUBSYSTEM linker option. To be honest, I wouldn't be surprised if that actually worked easier than a GNU toolchain for this matter.

I would be slightly cautious here. Whilst you may well get a PE file with the appropriate headers, note that the ABI used to compile the original code will still be the gcc default (probably sysV i386/AMD x64) rather than the Microsoft equivalent (which you need for UEFI). What this means is that the arguments to functions will be in the wrong place, and the stack alignment may be different, some registers may not be preserved across functions etc. This is only a problem when calling from your code to UEFI (and having UEFI functions call back to your own code e.g. with timers). There is a hack called gnu-efi which uses a stub function to rearrange function arguments for you, then uses objcopy, but it is not particularly robust.

There is an article on using gcc for UEFI here.

Regards,
John.

Thanks for providing this information. I didn't know that UEFI uses a different ABI - in fact, I haven't used UEFI before, I'm just curious to support it in my OS. Well, actually using a toolchain targeted for "x86_64-w64-mingw32" and fancy file system tools looks a bit horrible to me (not in the sense that it would be difficult, but it somehow looks like using a sledgehammer to crack a nut), but as far as I understood, there is only limited / broken support for UEFI targets in GCC / binutils.

Its been a while since I last looked at it. I've removed the dependency on mkfat to use mtools instead.

As not using the mingw32 toolchain, I suppose its possible to use the standard x86_64-elf cross-compiler with the -mabi=ms option and then objcopy it to a PE file, but I haven't had a chance to look into this.

Regards,
John.

It's been a while since I did that - but as far as I can remember that was really tricky. I don't remember any more details.

What I do right now is using a mingw32-w64 gcc/binutils, which outputs a perfectly valid binary. This works perfectly for me.

I've just tried to compile with Visual Studio subsystem EFI application,
only to be told the missing of some #defines found in auto generated files when compile with EDK2...

including,
_PCD_GET_MODE_*
_PCD_VALUE_*
_PCD_TOKEN_*

such as

#define _PCD_TOKEN_PcdVerifyNodeInList 23U
#define _PCD_GET_MODE_BOOL_PcdVerifyNodeInList _gPcd_FixedAtBuild_PcdVerifyNodeInList

EDK2 generate them with python...and _gPcd_*s seems to...as its name...fixed at build...