From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm0-x229.google.com (mail-wm0-x229.google.com [IPv6:2a00:1450:400c:c09::229]) (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 3CAAD1A1DFE for ; Thu, 4 Aug 2016 12:11:16 -0700 (PDT) Received: by mail-wm0-x229.google.com with SMTP id f65so5096888wmi.0 for ; Thu, 04 Aug 2016 12:11:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=references:mime-version:in-reply-to:content-transfer-encoding :message-id:cc:from:subject:date:to; bh=WCR8SoIqMsD9D7wRnTwAmroViN5nAhp1FTj9eZ8fRhY=; b=OoSDmOpEGkdPuSl/S3D7hxB2vLpQ3+LmIMQprMgd179TNgtTvz5yUM7IeuSJUW/0bv 46oi9rOvaQCqZ6944axNHQQtbPRrw6PUXlSxCJPUsTXMwrIqPnqyX3uUOIZsPKEqMw+v 6NdoSoKMspISRFIHMScX9OUAU58OrKu+244DY= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:references:mime-version:in-reply-to :content-transfer-encoding:message-id:cc:from:subject:date:to; bh=WCR8SoIqMsD9D7wRnTwAmroViN5nAhp1FTj9eZ8fRhY=; b=j6KoJfynSvFf4uAHtvVRHKfoKjRuE2+Uri8ieFrGJcEW2YDR+N/2oRY+GzBpb/Gnxq hWCRbNpVqcBDBlXkFKJEhHXnZOeWy+EfrBNlbYh8BS8Qw/nObcmbMkb09svX7xjIWnVj /+IeHo0dzrG1zMfCSr9jDBHb1HjG5xMkv6QnmfbvM5O6cwMl+3X7eR8kGz/RKpgexWIg HGHSF4+rFaSZdrYJqkoRLyc87+D4KvuO3ifdDLf0NI9iQCPajla/pQsGdTgRY5iSNr23 FngTX0Rw03gTlEZtH3U8LRHQJDRxk47kkGmyYWSsn8hg+7hLK99LLPCZ+OPbDRchWWHc k3Rg== X-Gm-Message-State: AEkoouvniF09gTxIkU0UdNUeCJWrxjl/d5h5PUzC/h3Fw5rPrCQ/x8WtoyHFC9MMKBaktsK6 X-Received: by 10.194.87.66 with SMTP id v2mr75256915wjz.40.1470337874220; Thu, 04 Aug 2016 12:11:14 -0700 (PDT) Received: from [192.168.1.34] (3.red-81-34-118.dynamicip.rima-tde.net. [81.34.118.3]) by smtp.gmail.com with ESMTPSA id q23sm4980014wme.17.2016.08.04.12.11.13 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 04 Aug 2016 12:11:13 -0700 (PDT) References: <1470300343-17287-1-git-send-email-ard.biesheuvel@linaro.org> <08b65ea6-3235-eb16-41bb-7f6bdcc42638@offblast.org> Mime-Version: 1.0 (1.0) In-Reply-To: <08b65ea6-3235-eb16-41bb-7f6bdcc42638@offblast.org> Message-Id: Cc: steven.shi@intel.com, yonghong.zhu@intel.com, liming.gao@intel.com, jordan.l.justen@intel.com, edk2-devel@lists.01.org X-Mailer: iPhone Mail (13G34) From: Ard Biesheuvel Date: Thu, 4 Aug 2016 21:11:09 +0200 To: Nicolas Owens Subject: Re: [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 19:11:16 -0000 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable > On 4 aug. 2016, at 21:03, Nicolas Owens wrote: >=20 > ard, >=20 > i think you need to have R_X86_64_PLT32 case in WriteRelocations64. > without that, i still hit the invalid relocation message. >=20 Good point. I will send out a v2 tomorrow >> On 08/04/2016 01:45 AM, Ard Biesheuvel wrote: >> 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. >>=20 >> 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). >>=20 >> So handle R_X86_64_PLT32 as a R_X86_64_PC32 relocation. >>=20 >> 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(+) >>=20 >> 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 =3D (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 i= s >> + // possible since we know all code symbol references resolve= to >> + // definitions in the same module (UEFI has no shared librar= ies), >> + // and so there is never a reason to jump via a PLT entry, >> + // allowing us to resolve the reference using the symbol dir= ectly. >> + // >> + VerboseMsg ("Treating R_X86_64_PLT32 as R_X86_64_PC32 ...");= >> + /* fall through */ >> case R_X86_64_PC32: >> // >> // Relative relocation: Symbol - Ip + Addend >>=20