From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm0-x22d.google.com (mail-wm0-x22d.google.com [IPv6:2a00:1450:400c:c09::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id 7ADF51A1E00 for ; Thu, 4 Aug 2016 01:45:51 -0700 (PDT) Received: by mail-wm0-x22d.google.com with SMTP id f65so475900815wmi.0 for ; Thu, 04 Aug 2016 01:45:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=from:to:cc:subject:date:message-id; bh=iZAwlLFcLfiUogP5v8TFTcTydOGIsfteynf1yilwKNU=; b=M7vEJOzTeAd9nmffHUltwPJkgN0PvJcuj/yVHqx8WY4fWmgMLrfIvfhoZU+QFwYQaO haAjgABxnjYyouhbyJnkJgt739oiBdFdEQiPjvelPKhTW9utFmFw9Bd6f87rC3hbexgL NsjaNHBjoUTqA/XMYuJG04J6rJtBrMj6SAR+Q= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:cc:subject:date:message-id; bh=iZAwlLFcLfiUogP5v8TFTcTydOGIsfteynf1yilwKNU=; b=eLSeEA7Qpz9flwf8PP7osq0ajNQ37WyjPIdBKlOw0hGwc4IWkwwfgsw7c1SnGo2YY5 YlnP1ptXgbHKldwaw8QjnAv/GND3rRQJwvWKtw3EENV2tdVsec8wDsKo8f0Bp57PwOdm 9GTLhVV0VJ8t/ipylZ8YwvhxfqoBpmO2G14yobNJrjklIhvz9Sz4k48iOzbxO+x0CV5c X4N5NG/JivCYqgSr6HT4TV/ge4JQTyor6lzp3a48ZUeqFcMdBPiWsNhrmAIMIK1dH+Pq s6BmpIpZrwZUVVTcR6OlP4lK6N0ixiCTFAxjXE7WvqGcLXBsv2bwgtcN4S1LLGRlpu9n jLIg== X-Gm-Message-State: AEkoouvyd5+oHzzyOOzTMFKTT+AoLBf+p7XNCNrbEDVWqlqMDaXIoZ22EozQgLqJt3AiAN0u X-Received: by 10.194.82.164 with SMTP id j4mr14691798wjy.157.1470300349378; Thu, 04 Aug 2016 01:45:49 -0700 (PDT) Received: from localhost.localdomain (3.red-81-34-118.dynamicip.rima-tde.net. [81.34.118.3]) by smtp.gmail.com with ESMTPSA id q187sm2472895wma.17.2016.08.04.01.45.47 (version=TLS1_2 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 04 Aug 2016 01:45:48 -0700 (PDT) From: Ard Biesheuvel To: steven.shi@intel.com, yonghong.zhu@intel.com, liming.gao@intel.com, jordan.l.justen@intel.com, edk2-devel@lists.01.org Cc: mischief@offblast.org, Ard Biesheuvel Date: Thu, 4 Aug 2016 10:45:43 +0200 Message-Id: <1470300343-17287-1-git-send-email-ard.biesheuvel@linaro.org> X-Mailer: git-send-email 2.7.4 Subject: [PATCH] BaseTools X64: fold PLT relocations into simple relative references X-BeenThere: edk2-devel@lists.01.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: EDK II Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Aug 2016 08:45:51 -0000 For X64/GCC, we use position independent code with hidden visibility to inform the compiler that symbols 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 Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Ard Biesheuvel --- BaseTools/Source/C/GenFw/Elf64Convert.c | 11 +++++++++++ 1 file changed, 11 insertions(+) diff --git a/BaseTools/Source/C/GenFw/Elf64Convert.c b/BaseTools/Source/C/GenFw/Elf64Convert.c index 944c94b8f8b4..7cbff0df0996 100644 --- a/BaseTools/Source/C/GenFw/Elf64Convert.c +++ b/BaseTools/Source/C/GenFw/Elf64Convert.c @@ -785,6 +785,17 @@ WriteSections64 ( *(INT32 *)Targ = (INT32)((INT64)(*(INT32 *)Targ) - SymShdr->sh_addr + mCoffSectionsOffset[Sym->st_shndx]); VerboseMsg ("Relocation: 0x%08X", *(UINT32*)Targ); break; + + case R_X86_64_PLT32: + // + // Treat R_X86_64_PLT32 relocations as R_X86_64_PC32: this is + // possible since we know all code symbol references resolve to + // definitions in the same module (UEFI has no shared libraries), + // and so there is never a reason to jump via a PLT entry, + // allowing us to resolve the reference using the symbol directly. + // + VerboseMsg ("Treating R_X86_64_PLT32 as R_X86_64_PC32 ..."); + /* fall through */ case R_X86_64_PC32: // // Relative relocation: Symbol - Ip + Addend -- 2.7.4