From: Zenith432 <zenith432@users.sourceforge.net>
To: <edk2-devel@lists.01.org>
Cc: <liming.gao@intel.com>
Subject: [PATCH] BaseTools/GenFw: Disable support for R_X86_64_32S
Date: Mon, 9 Jul 2018 09:36:51 +0000 (UTC) [thread overview]
Message-ID: <1903143001.1215482.1531129011285@mail.yahoo.com> (raw)
In-Reply-To: 1903143001.1215482.1531129011285.ref@mail.yahoo.com
REF:https://bugzilla.tianocore.org/show_bug.cgi?id=999
Cc: Liming Gao <liming.gao@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Zenith432 <zenith432@users.sourceforge.net>
---
BaseTools/Source/C/GenFw/Elf64Convert.c | 23 +++++++++++++++++++++++
1 file changed, 23 insertions(+)
diff --git a/BaseTools/Source/C/GenFw/Elf64Convert.c b/BaseTools/Source/C/GenFw/Elf64Convert.c
index 4636cfee..a4feaf7c 100644
--- a/BaseTools/Source/C/GenFw/Elf64Convert.c
+++ b/BaseTools/Source/C/GenFw/Elf64Convert.c
@@ -993,7 +993,30 @@ WriteRelocations64 (
+ (Rel->r_offset - SecShdr->sh_addr)),
EFI_IMAGE_REL_BASED_DIR64);
break;
+#if 0
+ //
+ // R_X86_64_32 and R_X86_64_32S are ELF64 relocations emitted when using
+ // the SYSV X64 ABI small non-position-independent code model.
+ // R_X86_64_32 is used for unsigned 32-bit immediates with a 32-bit operand
+ // size. The value is either not extended, or zero-extended to 64 bits.
+ // R_X86_64_32S is used for either signed 32-bit non-rip-relative displacements
+ // or signed 32-bit immediates with a 64-bit operand size. The value is
+ // sign-extended to 64 bits.
+ // EFI_IMAGE_REL_BASED_HIGHLOW is a PE relocation that uses 32-bit arithmetic
+ // for rebasing an image.
+ // EFI PE binaries declare themselves EFI_IMAGE_FILE_LARGE_ADDRESS_AWARE and
+ // may load above 2GB. If an EFI PE binary with a converted R_X86_64_32S
+ // relocation is loaded above 2GB, the value will get sign-extended to the
+ // negative part of the 64-bit address space. The negative part of the 64-bit
+ // address space is unmapped, so accessing such an address page-faults.
+ // In order to support R_X86_64_32S, it is necessary to unset
+ // EFI_IMAGE_FILE_LARGE_ADDRESS_AWARE, and the EFI PE loader must implement
+ // this flag and abstain from loading such a PE binary above 2GB.
+ // Since this feature is not supported, support for R_X86_64_32S (and hence
+ // the small non-position-independent code model) is disabled.
+ //
case R_X86_64_32S:
+#endif
case R_X86_64_32:
VerboseMsg ("EFI_IMAGE_REL_BASED_HIGHLOW Offset: 0x%08X",
mCoffSectionsOffset[RelShdr->sh_info] + (Rel->r_offset - SecShdr->sh_addr));
--
2.17.1
next parent reply other threads:[~2018-07-09 9:36 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <1903143001.1215482.1531129011285.ref@mail.yahoo.com>
2018-07-09 9:36 ` Zenith432 [this message]
2018-07-10 7:05 ` [PATCH] BaseTools/GenFw: Disable support for R_X86_64_32S Gao, Liming
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-list from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1903143001.1215482.1531129011285@mail.yahoo.com \
--to=devel@edk2.groups.io \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox