Octocontrabass wrote:
No sane compiler links UEFI applications as DLLs. With MSVC and Clang, you don't need to do anything special since relocations are not stripped by default. GCC has the "-pie" flag.
I've seen a few guides that recommend linking UEFI applications as DLLs, but I'm not sure why.
I don't think, MSVC linker v14.20 is old and I didn't do anything special, except setting /subsystem:EFI_APPLICATION and here is what it produces:
Quote:
E:\Valera>dumpbin /headers out\antosldr\aarch64\antload.efi
Microsoft (R) COFF/PE Dumper Version 14.20.27508.1
Copyright (C) Microsoft Corporation. All rights reserved.
Dump of file out\antosldr\aarch64\antload.efi
PE signature found
File Type: DLL
FILE HEADER VALUES
AA64 machine (ARM64)
4 number of sections
60D14129 time date stamp Tue Jun 22 04:47:21 2021
0 file pointer to symbol table
0 number of symbols
F0 size of optional header
2022 characteristics
Executable
Application can handle large (>2GB) addresses
DLL
as of not stripping relocations by default for EXEs, I see, it's true, but the quoted was from the current PE spec.
I am not sure what effect the gcc's -pie flag would have on PE targets, if any. in the ELF context, it's a total opposite to the PE approach, and it hardly would work for the latter, because PE loader does apply base relocations, that is fixes up addresses in the code and data itself, while -pie would require fixing up the contents of a special indirection table (GOT), which any PE loader (and UEFI's one as well) has no idea about. so that -pie thing would only work only if there is an ELF "interpreter" embedded into a resulting image, that would care about doing these crazy things on taking control over at the very start. such things are for bzt,
for some ELF-UEFI-POSIX.
I can see these recommendations given specifically because of the mentioned reason - to not get base relocations stripped by the linker that thinks they aren't needed for an EXE (which at least was the case in past as seen in the spec).