> On 16 jul. 2016, at 17:02, Shi, Steven <steven....@intel.com> wrote: > > If PIE can generate smaller code than PIC, why not use PIE? Why “We should > only enable it if we must” ? >
You are quite right. If you can show us a comparison between builds where the only difference is the presence of the -pie linker flag, and the PIE code is smaller, we should enable it. Note that PIE binaries typically require a runtime linker, and so they may be problematic when used with GDB, since absolute 64-bit relocations are not taken into account in the static binary image (e.g., function pointers in the .dll are all zeroes instead of populated with values that are correct relative to the preliminary base address), and so PIE has its downsides as well. Ard. > > Steven Shi > Intel\SSG\STO\UEFI Firmware > > Tel: +86 021-61166522 > iNet: 821-6522 > > From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org] > Sent: Saturday, July 16, 2016 10:45 PM > To: Shi, Steven <steven....@intel.com> > Cc: Andrew Fish <af...@apple.com>; edk2-devel-01 <edk2-devel@lists.01.org>; > Gao, Liming <liming....@intel.com>; Justen, Jordan L > <jordan.l.jus...@intel.com>; Kinney, Michael D <michael.d.kin...@intel.com> > Subject: Re: [PATCH v2 1/7] BaseTools-GenFw:Use EXE flag to check Elf section > type > > On 16 July 2016 at 15:54, Shi, Steven > <steven....@intel.com<mailto:steven....@intel.com>> wrote: > > Hi Ard, > > Sorry for my late response. For the PIC and PIE selection, my personal > opinion is to prefer the PIE rather than PIC, because PIE usually has even > smaller code size than PIC, although their difference is small (especially if > enable LTO). Below are some example data in my side. Also, like Andrew > mentioned, PIE is more secure than PIC, and more and more users use PIE > rather than PIC to generate the code. > > A PIE executable is built from PIC (*) objects, and simply contains a .rela > section and a _DYNAMIC entry point that allows a runtime linker to load it at > arbitrary offsets in memory. We already have this 'security' in EDK2 because > we use relocatable PE/COFF executables, so PIE does not bring us anything in > terms of features. > > (*) AARCH64 allows PIE executables to be built from non-PIC objects when > using the small model > > From a code generation point of view, they are identical, and only differ in > the linking step. > > > > > > > > I use your gcc-x64-opt and my llvm_v2 branches to collect the GCC49 and GCC5 > data > > Code size, > > Byte, > > the smaller the better > > > GCC49 with hidden visibility > > (PIE = PIC) > > > GCC49 with public visibility + my patch for new PIC/PIE relocation types > support in GenFw > > (PIC > PIE) > > > GCC5 LTO > > (PIC > PIE) > > > Shell X64 DEBUG PIC > > > 1,138,048 > > > 5,148,104 > > > 899,136 > > > Shell X64 DEBUG PIE > > > 1,138,048 > > > 5,130,464 > > > 899,072 > > > CpuDxe X64 DEBUG PIC > > > 67,456 > > > 68,608 > > > 36,032 > > > CpuDxe X64 DEBUG PIE > > > 67,456 > > > 67,456 > > > 35,968 > > > UsbKbDxe X64 DEBUG PIC > > > 46,784 > > > 47,296 > > > 26,752 > > > UsbKbDxe X64 DEBUG PIE > > > 46,784 > > > 46,784 > > > 26,688 > > > > You are changing several parameters at the same time, comparing > non-PIE/hidden with PIE/default visibility. > > PIE is not an optimization. PIE is an executable format that can be > understood by an ELF runtime linker, and so enabling PIE is not a goal in > itself. We should only enable it if we must. > > -- > Ard. > > > _______________________________________________ > edk2-devel mailing list > edk2-devel@lists.01.org > https://lists.01.org/mailman/listinfo/edk2-devel _______________________________________________ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
