Thanks for checking. The problem with GCC5 is that the fact that '_ModuleEntryPoint' is also hidden, which confuses the LTO code and makes it eliminate all input objects. I think this is a bug in

[Steven]: Do you mean the linker will apply above optimization but not remove the original GOTPCREL item? It sounds like a severe linker bug. [Steven]: I still don't understand why there will be

Yes, Contributed-under and Signed-off-by are required. I think it is possible in some cases to submit a third party conribution, but you still have to add the Contributed-under and Signed-off-by. See

I checked quickly, and it appears the linker does the right thing here, i.e., it performs the optimization and also modifies the relocation emitted into the .rela.text section So this: .globl

When using GCC to build for X64, we switched to the position independent small code model, which is much more efficient in terms of code generation and runtime relocation footprint, and produces

They may require a depex, but, as mentioned below, they can also add it directly in the .fdf. As it stands, apparently we have 1 .depex file in the tree, and it is unused. Aside from this, under what

Use StatusCode Router and Handler from MdeModulePkg instead of IntelFrameworkModulePkg. MdeModulePkg ones follows PI spec to implement StatusCode Router/Handler and provide StatusCode service. It

[Steven]: the 'return n' will not result in relocation, but the 'int n' will result in the relocation in GOT. The three 'return n' will point to the same 'int n' relocation item. So, we need only

Every 'return n' will result in a GOTPCREL relocation against n. And your code emits a relocation for the GOT entry every time. BTW, the 'int n' relocation type in your code on X64 should

[Steven]: I don't think so. please give a real case and offer its source code to prove " Every 'return n' will result in a GOTPCREL relocation against n ". [Steven]: the current GenFw will ignore

Compiling the code above using gcc -c -O -fpic /tmp/pie.c -o pie.o and dumping it using readelf -r pie.o gives me Relocation section '.rela.text' at offset 0x250 contains 3 entries: Offset

This v5 to introduce GCC5 is now a 8 piece series, including some preparatory cleanup patches that allow all GCC4x and CLANG35 toolchains to switch to using 'gcc' as the linker. This allows us to get

Some versions of Clang fail on every input file when using the -save-temps options, and produces the following heplful error message: <unknown>:0: error: Undefined temporary symbol Simply dropping

Newer versions of ld automatically emit .gnu.hash and .note.gnu.build-id sections, which are not listed in the linker script, and will end up breaking the build with an allocation conflict, e.g.,

Before we can make non-backward compatible changes to the GCC build rules regarding the use of the 'gcc' binary as the linker, clone the existing GCC build rules into a 'GCCLD' build rule family, and

To accommodate upcoming GCCx toolchain versions that require 'gcc' to be used as the linker in order to support LTO, switch GCC44 and later (including CLANG35) to a new DLINK build rule that invokes

GCC in LTO mode interoperates poorly with non-standard libraries that provide implementations of compiler intrinsics such as memcpy/memset or the stack protector entry points. Such libraries need to

Recent versions of GNU ld automatically emit a .notes section into the ELF binary containing a build id. Since this is an allocatable section by default, it will be identified by GenFw as a

When building with LTO enabled, the LTO routines infer from the 'hidden' visibility of the _ModuleEntryPoint symbol that its code only needs to be retained if it is referenced internally, and

This adds support for GCC 5.x in LTO mode for IA32, X64, ARM and AARCH64. Due to the fact that the GCC project switched to a new numbering scheme where the first digit is now incremented for