UEFI in assembler

[nullplan]

That's why it's not PIC, because PIC means no references to absolute addresses at all, all references are relative, for example, to the program counter.

Well, in ELF, PIC just means that all accesses to memory happen through a separate pointer table (that gets fixed up by the loader). But I suppose the difference for PE would be rather small. It would just be whether the relocations affect code directly, or only data referenced by code.

PE does require RIP-relative addressing if the executable might be loaded above 2GB. That's probably the reason why PIC is always enabled for 64-bit Windows targets.

That and the fact that RIP-relative addressing makes PIC rather trivial for AMD64. But yes, I forgot you can only have four bytes offsets to most instructions.

[Korona]

Well, in ELF, PIC just means that all accesses to memory happen through a separate pointer table (that gets fixed up by the loader).

That's not entirely accurate. It is true that there are two tables, namely the PLT and the GOT but at least the PLT is not strictly required for PIC. The PLT is used for lazy binding and to implement that library calls can be intercepted by libraries that occur earlier in the load order (e.g., LD_PRELOAD lirbaries). You can build ELF DSOs that do not use a PLT by passing -fno-plt, but lazy binding will not work anymore if you do. The GOT (which is really just a plain data segment with no special handling outside of lazy binding) is required to load the same DSO to multiple locations: in the ELF model, you can share text and rodata segments between multiple instances of the same DSO. That is not possible in the PE model since PE modifies the text segment. The PE model is roughly equivalent to ELF object files (linked together with -r; for example, this strategy is used to build Linux kernel modules).

[nullplan]

That's not entirely accurate.

So where was any of what I wrote inaccurate? I'm still waiting. You expanded on my paraphrase, and gave the proper nouns for the table I mentioned, and also mentioned the PLT for some odd reason. But you never showed any of what I wrote to be wrong or incomplete.

The PLT only exists to unify the calling sequences, to allow non-PIC code to be linked with PIC code, and to group the code pointers in the GOT together (to facilitate lazy binding). But heart and soul of ELF PIC is the GOT. There is one exception I know of, and it is the original PowerPC ABI, the one with the BSS PLT. What were they thinking? But that ABI is no longer in use, and for example musl doesn't support it. In all other ABIs, the PLT stub will merely jump to the function through the GOT pointer.

Not that any of this has any bearing on the original subject. The GOT is only needed for external symbols, and there are no external symbols in UEFI (the system table contains function pointers instead), and UEFI uses PE instead of ELF. UEFI doesn't even exist for PowerPC!

[Korona]

So where was any of what I wrote inaccurate? I'm still waiting.

I guess it was also not entirely inaccurate; but it's not the full story in the sense that ELF doesn't require all accesses to go through a table -- you can build ELFs that do not use indirection tables: namely, if you do not require lazy binding and you do not require the DSO to share its text segment with multiple processes. The ELF model supports a superset of the features of PE (regarding PIC). I brought up the PLT because out of the two tables, the PLT is the one that is special-cased by the linker and that is responsible for indirection -- I thought you meant the PLT when you stated "indirection table". The GOT is merely a part of the normal data segment (except for the first two entries, which handle the PLT).

[zaval]

Well, in ELF, PIC just means that all accesses to memory happen through a separate pointer table (that gets fixed up by the loader). But I suppose the difference for PE would be rather small. It would just be whether the relocations affect code directly, or only data referenced by code.

I thought, if code and data contains absolute addresses, it's called Position Dependent Code. That's what it is in PE. If it's PIC as well, then what is non PIC?

PE does require RIP-relative addressing if the executable might be loaded above 2GB. That's probably the reason why PIC is always enabled for 64-bit Windows targets.

I am lazy to check if there are x64 base relocation types in the PE spec, but I just looked at my loader, full of global variables and indeed - for the x64 and arm64 images, Base Relocation Directory is empty, where it's not empty for arm32. So, at least specifics of architectures, make images truely PIC. Of course, ELF PIC is quazi PIC, since it needs fixing anyway. Just special "indirection" tables, rather the code/data as in PE.

[Octocontrabass]

I am lazy to check if there are x86 base relocation types in the PE spec, but I just looked at my loader, full of global variables and indeed - for the x64 and arm64 images, Base Relocation Directory is empty, where it's not empty for arm32.

There can still be relocation entries. For example, initialize one of your global variables with a function pointer.