Parse the intermediate ELF file directly instead of using libbfd, in
order to allow for cross-compiled ELF objects.
As a side bonus, this eliminates libbfd as a build requirement.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
[efi] Work around broken 32-bit PE executable parsing in ImageHlp.dll
The Microsoft PE/COFF specification defines the MajorLinkerVersion and
MinorLinkerVersion fields as "The linker major version number" and
"The linker minor version number" respectively, and has nothing more
to say on the matter. These fields have no significance: they do not
affect the interpretation of the remainder of the file, but merely
provide diagnostic information for interested humans to read.
Apparently, versions 2.4 and earlier of the Microsoft linker produced
binaries so incorrigibly cursed that even to attempt to parse such a
binary would risk summoning a plague of enraged spiders. To protect
users from unwanted arachnids, ImageHlp.dll's MapAndLoad() function
will helpfully fail to map and/or load a 32-bit binary unless the
linker version field indicates version 2.5 or later. (64-bit binaries
are exempt from such helpfulness.)
Work around the broken Microsoft ImageHlp.dll library by providing a
linker version number that will satisfy the arbitrary whims of the
MapAndLoad() function.
This mirrors wimboot commit 670c7e2 ("[efi] Work around broken 32-bit
PE executable parsing in ImageHlp.dll").
Signed-off-by: Michael Brown <mcb30@ipxe.org>
[efi] Minimise use of iPXE header files when building host utilities
Avoid dragging in unnecessary iPXE header files such as <ipxe/uuid.h>
and <ipxe/tables.h> when building host utilities, and ensure that
FILE_LICENCE() (present in the imported EDK2 headers) expands to a
no-op.
Reported-by: Michael Tautschnig <mt@debian.org>
Signed-off-by: Michael Brown <mcb30@ipxe.org>
The debug directory size specified in the data directory should cover
only the EFI_IMAGE_DEBUG_DIRECTORY_ENTRY structure, not the whole of
the .debug section.
Reported-by: Andreas Hammarskjöld <junior@2PintSoftware.com>
Signed-off-by: Michael Brown <mcb30@ipxe.org>
At some point in the past few years, binutils became more aggressive
at removing unused symbols. To function as a symbol requirement, a
relocation record must now be in a section marked with @progbits and
must not be in a section which gets discarded during the link (either
via --gc-sections or via /DISCARD/).
Update REQUIRE_SYMBOL() to generate relocation records meeting these
criteria. To minimise the impact upon the final binary size, we use
existing symbols (specified via the REQUIRING_SYMBOL() macro) as the
relocation targets where possible. We use R_386_NONE or R_X86_64_NONE
relocation types to prevent any actual unwanted relocation taking
place. Where no suitable symbol exists for REQUIRING_SYMBOL() (such
as in config.c), the macro PROVIDE_REQUIRING_SYMBOL() can be used to
generate a one-byte-long symbol to act as the relocation target.
If there are versions of binutils for which this approach fails, then
the fallback will probably involve killing off REQUEST_SYMBOL(),
redefining REQUIRE_SYMBOL() to use the current definition of
REQUEST_SYMBOL(), and postprocessing the linked ELF file with
something along the lines of "nm -u | wc -l" to check that there are
no undefined symbols remaining.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
UEFI binaries may be relocated to any location within the 64-bit
address space. We compile as position-independent code with hidden
visibility, which should force all relocation records to be either
PC-relative (in which case no PE relocations are required) or full
64-bit relocations. There should be no R_X86_64_32 relocation
records, since that would imply an invalid assumption that code could
not be relocated above 4GB.
Remove support for R_X86_64_32 relocation records from util/elf2efi.c,
so that any such records result in a build failure rather than a
potential runtime failure.
Reported-by: Jan Kundrát <jkt@kde.org>
Signed-off-by: Michael Brown <mcb30@ipxe.org>
Newer versions of bfd.h require definitions for the PACKAGE and
PACKAGE_VERSION macros used by autotools. Work around this by
manually defining these macros before including bfd.h.
Originally-fixed-by: Brandon Penglase <bpenglase-ipxe@spaceservices.net>
Tested-by: Brandon Penglase <bpenglase-ipxe@spaceservices.net>
Signed-off-by: Michael Brown <mcb30@ipxe.org>
[efi] Ensure EFI binaries comply with Authenticode requirements
Authenticode requires that the size of the raw file must equal the
size of the OptionalHeader.SizeOfHeaders plus the sum of all sections'
SizeOfRawData.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
Currently, if elf2efi.c is compiled using a 32-bit HOST_CC, then the
resulting elf2efi64 binary will generate 32-bit EFI binaries instead
of 64-bit EFI binaries.
The problem is that elf2efi.c uses the MDE_CPU_* definitions to decide
whether to output a 32-bit or 64-bit PE binary. However, MDE_CPU_*
gets defined in ProcessorBind.h, depending on the compiler's target
architecture. Overriding them on the command line doesn't work in the
expected way, and you can end up in cases where both MDE_CPU_IA32 and
MDE_CPU_X64 are defined.
Fix by using a separate definition, EFI_TARGET_IA32/EFI_TARGET_X64,
which is specified only on the command line.
Signed-off-by: Geoff Lywood <glywood@vmware.com>
Signed-off-by: Michael Brown <mcb30@ipxe.org>
Currently, if you attempt to build 64-bit EFI binaries on a 32-bit
system without a suitable cross-compiling version of libbfd, the iPXE
build will die with a segmentation fault in elf2efi64.
Fix by properly handling the return value from bfd_check_format().
Signed-off-by: Michael Brown <mcb30@ipxe.org>
Access to the gpxe.org and etherboot.org domains and associated
resources has been revoked by the registrant of the domain. Work
around this problem by renaming project from gPXE to iPXE, and
updating URLs to match.
Also update README, LOG and COPYRIGHTS to remove obsolete information.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
elf2efi converts a suitable ELF executable (containing relocation
information, and with appropriate virtual addresses) into an EFI
executable. It is less tightly coupled with the gPXE build process
and, in particular, does not require the use of a hand-crafted PE
image header in efiprefix.S.
elf2efi correctly handles .bss sections, which significantly reduces
the size of the gPXE EFI executable.
Michael Brown