Talk:UEFI App Bare Bones

Hello World

Without wanting to overly criticise the content of the article, would 'UEFI Hello World' be a better title for this article? The article, while very relevant to operating system development, has very little in common with the theme of the 'Bare Bones' series of articles contained on this site. A more relevant 'UEFI Bare Bones' article could be written as an addendum to one of the other bare bones articles that more completely demonstrates how to create a UEFI bootloader. I recently came upon this article while searching for a basic introduction to implementing UEFI compatibility into a hobby OS. While it does provide a very good introduction to the topic, I feel that it's overly general. I understand the pedagogical value in not just spoonfeeding the audience copy+pasteable answers to complex topics like developing bootloader, but the topic of UEFI in the context of osdev is much more specialised and as a result this title is a bit misleading. --Ajxs 08:31, 11 August 2019 (CDT)

GNU-EFI and Toolchain

I'm not sure why the author of the article has decided not to link against full GNU-EFI. The reason given is "To avoid bloat and unnecessary dependencies on the rest of gnu-efi", this seems really unnecessary. It would seem simpler for the purpose of a 'Hello World' style app to take the path of least resistance and link against GNU-EFI in its complete form rather than editing its headers and selectively copying and including it in the source tree. This seems like a bad practice to me. Is the author using a cross compiler to avoid assuming that the user is using x86_64-elf-gcc? I've been successful using x86_64-elf-gcc and using objcopy to create the final binary in efi-app-x86_64 format. This seems like a simpler approach. If there's a good reason not to do this, I would appreciate being told! --Ajxs 08:31, 11 August 2019 (CDT)

GNU-EFI performs some questionable stuff to make ELFs run on UEFI, which expects a specific type of a PE (or related format, don't quote me on the exact name). It does this by compiling everything as an ELF and modifying it to appear as a PE, including forging relocations (IIRC). This is just a horrible hack, needless to say, especially given that you could just use a mostly appropriate compiler, as done in the article (on clang, you would just use the x86_64-pc-win32-coff target and the appropriate linker flags). The point of using this specific cross-compiler is to avoid this mess by actually producing an appropriate file. If you want your kernel to be an ELF, just have a UEFI loader that loads the kernel (use could use this to position your kernel at the -2 GiB mark) and passes control to it. However, personally I just steal Zircon's UEFI headers and work with them to load my kernel. no92 10:35, 11 August 2019 (CDT)

I'm not sure I understand what you mean here. You ( and the article's author ) refer to GNU-EFI as having/being some kind of a toolchain/build system. GNU-EFI is just a library is it not? If you compile the main EFI executable using x86_64-elf-gcc and link against GNU-EFI, the output will be a completely valid ELF file. Using readelf/objdump on the output confirms this. GNU-EFI has no idea about the target executable format. My build pipeline involves compiling my bootloader as an ELF static lib that links statically against GNU-EFI, and then copying the resulting .so to a PE executable. This seems to work absolutely fine. I'm ready to be corrected, however. Are you referring to using objcopy --target=efi-app-x86_64 to create a PE executable from the ELF file, or am I misunderstanding something?

As for creating an ELF loader to load the kernel from within the bootloader, I had assumed that this was a standard approach. I've seen a few examples online where people have compiled their kernel into the same EFI executable as the bootloader, but I thought this was unusual. --Ajxs 01:27, 12 August 2019 (CDT)

There's more going on than just linking in a static library (e.g. forging relocations, providing a linker script that they say apps have to use). The whole point of this monstrosity is to create an UEFI executable, which you could just do with a header-only library and the correct compiler, instead of relying on this massive hack to make ELFs run on UEFI. Adding points of failure in code that is being compiled incorrectly just isn't a good idea to begin with, with the alternative way being simpler (and, this may be a point too, doesn't introduce additional dependencies on make, and therefore, extra steps). no92 09:51, 12 August 2019 (CDT)

Thanks for pointing that out! I see your point. That does sound pretty fragile. Without researching more into it I had assumed that objcopy was doing all of the heavy lifting here. Once I'm done with reading and working through all of this I might update the tutorial to point this out, since I don't think it's immediately obvious. Thanks again.