> On Jul 12, 2016, at 9:55 AM, Ard Biesheuvel <ard.biesheu...@linaro.org> wrote: > > On 11 July 2016 at 17:52, Shi, Steven <steven....@intel.com> wrote: >> If the cost of the large model is due to its use of 64-bit quantities, how >> is this any better with PIC/PIE binaries? The primary difference is that you >> now have a Global Offset Table (GOT) entry for all symbol references, which >> also contains 64-bit values. Do you have any numbers comparing the large >> model to PIC/PIE? You should also be aware that GCC's default visibility >> setting results in all symbol references to go via the GOT, which may not be >> what you want. (This is required for ELF symbol preemption, which does not >> make sense in a PIE executable, but GCC does not know about that when it >> creates the .o from the .c). Also, do you have any comparisons for the size >> of the .reloc section? >> >> >> >> [Steven] As I mentioned in previous email, it is the small code size model, >> not PIC/PIE, to make the code size smaller. >> >> “It is worthy to mention that PIE/PIC can increase code size in fact, >> because more code need to make the addressing position independent. But >> PIE/PIC can guarantee the small code model is safe in 64bits anywhere, and >> the small code can decrease the 64bits code size sharply. So the PIE+Small >> code overall can generate smaller code size than large code. A tricky >> scenario is that if you can make sure your 64bits code only run under 4GB >> address, you can disable PIE but only enable small code model, then you will >> get even smaller 64bits binary.” >> > > OK, so in summary, the AMD64 small model not only limits the relative > range but also the absolute placement of the code? This is different > from AArch64, where the tiny and small models only limit the range of > symbol references, but the code can still execute anywhere (and > relative jumps have a range that is +/- 128 MB, regardless of the code > model) > > So I understand why you need the build the objects using -fpic. But > why are you linking a PIE executable? Is that required? The only thing > that it buys you is the redundant RELA section with the SHF_ALLOC > attribute set, and its contents are redundant in the presence of > -q/--emit-relocs. > > A quick test build of DxeCore.efi in RELEASE mode with GCC48 shows > that linking small model PIC objects without PIE already results in a > significant size reduction (182 KB -> 160 KB) I don't have any newer > X64 GCC versions installed, so I did not try any of those. (Note that > this requires your patch to add support for PIC-specific ELF > relocations to GenFw) >
Ard, I'm not sure if this is related, but the Xcode/clang linker for x86_64 only supports PIE. This is only an issue when making .S (.nasm) files common as some times they will fail to link with Xcode and we have to change code to use RIP relative addressing. I remember Steven was having a code generation issue with clang and turning on PIE fixed it. We also need the PIE support for the macOS native tools, but they generate Mach-O and do not use GenFw. So at this point I think PIE is required for clang. I guess Steven could investigate using other models, but I'm guessing that is not a common usage case with clang as PIE is required for macOS and also from ASLR. Thus it might be broken, or it might not be obvious how to make clang and the linker happy. Thanks, Andrew Fish >> Current GCC49 is large code model. In my last patch, I have some code size >> data to compare them as blow: >> >> GCC49: large code model >> >> CLANG38 and GCC 5: small code model + PIE >> >> >> >> Module (KB) VS2015x86 | GCC49 | CLANG38 | GCC5 >> >> ----------------------------------------------------------------------------------- >> >> RELEASE X64 DxeCore.efi 95.3KB | 183KB | 101KB | 91.2KB >> >> DEBUG X64 DxeCore.efi 138KB | 273KB | 138KB | 137KB >> > > Is this all without LTO? > > -- > Ard. _______________________________________________ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
