https://bugzilla.tianocore.org/show_bug.cgi?id=417
The commit makes the following refinements in GenFw source codes to
avoid VS2010/VS2012 build failure:
1. Replaces the uses of 'bool' with 'BOOLEAN' for accordance, and remove
the header file dependency for '<stdbool.h>'.
2. Refines coding style for function 'GetSymName' to declare local
variables at the beginning of the function block.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Hao Wu <hao.a.wu@intel.com>
Reviewed-by: Yonghong Zhu <yonghong.zhu@intel.com>
When building PIE (ET_DYN) executables, an additional RELA section is
emitted (in addition to the per-section .rela.text and .rela.data sections)
that is intended to be resolved at runtime by a ET_DYN compatible loader.
At the moment, due to the fact that we don't support GOT based relocations,
this dynamic RELA section only contains relocations that are redundant,
i.e., each R_xxx_RELATIVE relocation it contains duplicates a R_xxx_xx64
relocation appearing in .rela.text or .rela.data, and so we can simply
ignore this section (and we already ignore it in practice due to the fact
that it points to the NULL section, which has the SHF_ALLOC bit cleared).
For example,
Section Headers:
[Nr] Name Type Address Offset
Size EntSize Flags Link Info Align
[ 0] NULL 0000000000000000 00000000
0000000000000000 0000000000000000 0 0 0
[ 1] .text PROGBITS 0000000000000240 000000c0
000000000000427c 0000000000000008 AX 0 0 64
[ 2] .rela.text RELA 0000000000000000 00009310
0000000000001bf0 0000000000000018 I 7 1 8
[ 3] .data PROGBITS 00000000000044c0 00004340
00000000000046d0 0000000000000000 WA 0 0 64
[ 4] .rela.data RELA 0000000000000000 0000af00
0000000000000600 0000000000000018 I 7 3 8
[ 5] .rela RELA 0000000000008bc0 00008a10
0000000000000600 0000000000000018 0 0 8
[ 6] .shstrtab STRTAB 0000000000000000 0000b500
0000000000000037 0000000000000000 0 0 1
[ 7] .symtab SYMTAB 0000000000000000 00009010
0000000000000210 0000000000000018 8 17 8
[ 8] .strtab STRTAB 0000000000000000 00009220
00000000000000eb 0000000000000000 0 0 1
Relocation section '.rela.data' at offset 0xaf00 contains 64 entries:
Offset Info Type Sym. Value Sym. Name + Addend
000000004800 000100000001 R_X86_64_64 0000000000000240 .text + 3f5b
000000004808 000100000001 R_X86_64_64 0000000000000240 .text + 3f63
000000004810 000100000001 R_X86_64_64 0000000000000240 .text + 3f79
000000004818 000100000001 R_X86_64_64 0000000000000240 .text + 3f90
000000004820 000100000001 R_X86_64_64 0000000000000240 .text + 3fa6
...
Relocation section '.rela' at offset 0x8a10 contains 64 entries:
Offset Info Type Sym. Value Sym. Name + Addend
000000004800 000000000008 R_X86_64_RELATIVE 419b
000000004808 000000000008 R_X86_64_RELATIVE 41a3
000000004810 000000000008 R_X86_64_RELATIVE 41b9
000000004818 000000000008 R_X86_64_RELATIVE 41d0
000000004820 000000000008 R_X86_64_RELATIVE 41e6
000000004828 000000000008 R_X86_64_RELATIVE 41ff
...
Note that GOT based relocations result in entries that *only* appear in the
dynamic .rela section and not in .rela.text or .rela.data. This means two
things if we intend to add support for GOT based relocations:
- we must check that a dynamic RELA section exists;
- we must filter out duplicates between .rela and .rela.xxx, to prevent
emitting duplicate fixups into the PE/COFF .reloc section.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Liming Gao <liming.gao@intel.com>
For X64/GCC, we use position independent code with hidden visibility
to inform the compiler that symbol references are never resolved at
runtime, which removes the need for PLTs and GOTs. However, in some
cases, GCC has been reported to still emit PLT based relocations, which
we need to handle in the ELF to PE/COFF perform by GenFw.
Unlike GOT based relocations, which are non-trivial to handle since the
indirections in the code can not be fixed up easily (although relocation
types exist for X64 that annotate relocation targets as suitable for
relaxation), PLT relocations simply point to jump targets, and we can
relax such relocations by resolving them using the symbol directly rather
than via a PLT entry that does nothing more than tail call the function
we already know it is going to call (since all symbol references are
resolved in the same module).
So handle R_X86_64_PLT32 as a R_X86_64_PC32 relocation.
Suggested-by: Steven Shi <steven.shi@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Liming Gao <liming.gao@intel.com>
The ADRP instruction in the AArch64 ISA requires the link time and load time
offsets of a binary to be equal modulo 4 KB. The reason is that this instruction
always produces a multiple of 4 KB, and relies on a subsequent ADD or LDR
instruction to set the offset into the page. The resulting symbol reference
only produces the correct value if the symbol in question resides at that
exact offset into the page, and so loading the binary at arbitrary offsets
is not possible.
Due to the various levels of padding when packing FVs into FVs into FDs, this
alignment is very costly for XIP code, and so we would like to relax this
alignment requirement if possible.
Given that symbols that are sufficiently close (within 1 MB) of the reference
can also be reached using an ADR instruction which does not suffer from this
alignment issue, let's replace ADRP instructions with ADR after linking if
the offset can be encoded in this instruction's immediate field. Note that
this only makes sense if the section alignment is < 4 KB. Otherwise,
replacing the ADRP has no benefit, considering that the subsequent ADD or
LDR instruction is retained, and that micro-architectures are more likely
to be optimized for ADRP/ADD pairs (i.e., via micro op fusing) than for
ADR/ADD pairs, which are non-typical.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Leif Lindholm <leif.lindholm@linaro.org>
current GCC build report error: 'for' loop initial declarations are only
allowed in C99 or C11 mode, the patch fix this failure.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Yonghong Zhu <yonghong.zhu@intel.com>
Reviewed-by: Liming Gao <liming.gao@intel.com>
This patch revises multiple diagnostic messages to use correct
datatypes. It also checks that a symbol name that is about to be used
in a diagnostic message is terminated by a null character within the
contents of the string table section so that the print routine does
not read past the end of the string table section contents when
reading the symbol name.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Michael LeMay <michael.lemay@intel.com>
Reviewed-by: Yonghong Zhu <yonghong.zhu@intel.com>
This patch expands the error message that is output when GenFw
encounters a bad symbol definition or an unsupported symbol type. It
displays the symbol name, the symbol address, and a message that
describes both possibilities (bad symbol definition or unsupported
symbol type). It also provides two examples of unsupported symbol
types.
Furthermore, this patch revises the conditional for detecting bad
symbol definitions to eliminate a redundant test (a Sym->st_shndx
value of SHN_ABS should certainly be greater than mEhdr->e_shnum) and
to change another test from 'Sym->st_shndx > mEhdr->e_shnum' to
'Sym->st_shndx >= mEhdr->e_shnum' for consistency with the test in
GetShdrByIndex.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Michael LeMay <michael.lemay@intel.com>
Reviewed-by: Yonghong Zhu <yonghong.zhu@intel.com>
This patch revises GetPhdrByIndex and GetShdrByIndex to cause GenFw to
exit with an error message when a section header lookup fails. The
current behavior of those functions in such circumstances is to return
NULL, which can cause GenFw to subsequently fault when it attempts to
dereference the null pointer.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Michael LeMay <michael.lemay@intel.com>
Reviewed-by: Yonghong Zhu <yonghong.zhu@intel.com>
This adds support to the ELF to PE/COFF conversion performed by GenFw for
the AArch64 ELF relocation types R_AARCH64_PREL64, R_AARCH64_PREL32 and
R_AARCH64_PREL16. Since we already require the ELF and PE/COFF section
layouts to be identical in order to support other relative relocation
types, this is simply a matter of whitelisting these new relocation types
in the same way.
While we're at it, clean up the code a bit, and add a comment explaining
why these relocations are ignored in WriteRelocations64 ().
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Leif Lindholm <leif.lindholm@linaro.org>
Reviewed-by: Liming Gao <liming.gao@intel.com>
ARM and RVCT apply to 32-bit code only, so remove any references
to them (including the workaround for the linker) from the 64-bit
version of ElfConvert.c
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Leif Lindholm <leif.lindholm@linaro.org>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@18539 6f19259b-4bc3-4df7-8a09-765794883524
SVN commit r18077 ("BaseTools/GenFw: move .debug contents to .data to
save space") removed the separate .debug section after moving its
contents into .text or .data. However, this change does not take into
account that some of these contents need to appear at a 32-bit aligned
offset. So align the debug data RVA to 32 bits.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Liming Gao <liming.gao@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@18443 6f19259b-4bc3-4df7-8a09-765794883524
The AArch64 small C model makes extensive use of ADRP/ADD and
ADRP/{LDR,STR} pairs to emit PC-relative symbol references with
a +/- 4 GB range. Since the relocation pair splits the relative
offset into a relative page offset and an absolute offset into
a 4 KB page, we need to take extra care to ensure that the target
of the relocation preserves its alignment relative to a 4 KB
alignment boundary.
Also, due to a problem with the --emit-relocs GNU ld option, where
it does not recalculate the addends for section relative relocations,
the only way to guarantee correct code is by requiring the relative
section offset to be equal in the ELF and PE/COFF versions of the
binary. This affects both the 'tiny' and 'small' GCC code models.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Leif Lindholm <leif.lindholm@linaro.org>
Tested-by: Leif Lindholm <leif.lindholm@linaro.org>
Reviewed-by: Liming Gao <liming.gao@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@18197 6f19259b-4bc3-4df7-8a09-765794883524
The secondary header (not the DOS header) of a PE/COFF binary
does not reside at a fixed offset. Instead, its offset into the
file is recorded in the DOS header.
This gives us the flexibility to move it, along with the section
headers, to right before the first section if there is considerable
space before it, i.e., when the PE/COFF file alignment is substantially
larger than the size of the header.
Since the PE/COFF to TE conversion replaces everything before the
section headers with a simple TE header, this change removes all
the header padding from such images, leading to smaller files.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Liming Gao <liming.gao@intel.com>
Reviewed-by: Yingke Liu <yingke.d.liu@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@18078 6f19259b-4bc3-4df7-8a09-765794883524
In order to reduce the memory footprint of PE/COFF images when
using large values for the PE/COFF section alignment, move the
contents of the .debug section to data, and point the debug data
directory entry to it. This allows us to drop the .debug section
entirely, as well as any associated rounding. Since our .debug
section only contains the filename of the ELF input image, the
penalty of keeping this data in a non-discardable section is
negligible.
Note that the PE/COFF spec v6.3 explicitly mentions that this is
allowed.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Liming Gao <liming.gao@intel.com>
Reviewed-by: Yingke Liu <yingke.d.liu@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@18077 6f19259b-4bc3-4df7-8a09-765794883524
Get maximum section alignment from each ELF section, and this alignment is used to create PE header.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Liming Gao <liming.gao@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@17727 6f19259b-4bc3-4df7-8a09-765794883524
Before this change the alignment of the first data section was not taken into account.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Erik Bjorge <erik.c.bjorge@intel.com>
Reviewed-by: Liming Gao <liming.gao@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16831 6f19259b-4bc3-4df7-8a09-765794883524
When R_AARCH64_CALL26/R_AARCH64_JUMP26 relocations referred to static
functions, they sometime refer to the start of the '.text' section + addend.
It means the addend is different of '0'.
The non-patched code (before applying the relocation) already contains
the correct offset.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Olivier Martin <olivier.martin@arm.com>
Reviewed-by: Yingke Liu <yingke.d.liu@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16302 6f19259b-4bc3-4df7-8a09-765794883524
relocations
- ADR_PREL_LO21: support for loading a PC relative label offset.
- R_AARCH64_CONDBR19: support for conditional branch instruction (ELF64 code: 280).
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Harry Liebel <Harry.Liebel@arm.com>
Signed-off-by: Olivier Martin <olivier.martin@arm.com>
Reviewed-by: Yingke Liu <yingke.d.liu@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@15745 6f19259b-4bc3-4df7-8a09-765794883524
Hao Wu
Ard Biesheuvel
Yonghong Zhu
Michael LeMay
Erik Bjorge
Olivier Martin
Yingke Liu
Harry Liebel
Gao, Liming
lgao4