From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pf0-x242.google.com (mail-pf0-x242.google.com [IPv6:2607:f8b0:400e:c00::242]) (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 885C51A1DFE for ; Thu, 4 Aug 2016 12:03:35 -0700 (PDT) Received: by mail-pf0-x242.google.com with SMTP id i6so18738251pfe.0 for ; Thu, 04 Aug 2016 12:03:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=offblast-org.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding; bh=f1PooMCbLJ7Pn+Y9z8+8oyVVVoC+UwHO7+xqzArDBck=; b=0IKNh4mJUqavBfvrFhd9b4Rsy4v/kIxCytUceTfiGvwUY70UHWAKi1/yiHjlr/j+TO XdXDwhzwy5qqS/SQx5oz6O3Rb5Yy0JmhoMoBKssSi3+gNwVoirPnILPP7qtmG9dCEPZu T244EY8P7uDWry7qHx0OMd0Ur7TmRG+SGW4a81GUFLkCaRLcWk/X2vZDNy+fUZRzSy2b fWK8HIVd8jZBP0bUjKCkFvnQY9xY/erJAWwq8zY0P1PfNOVOMl037yBBYSLNQXYkB27a lGCulKbhB1QqKbFLgdQBZJ/z7uCG4HqajGOZIW9SvS4kPKVcHuk6twxdhZDqF9k4u/vY Z5OQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=f1PooMCbLJ7Pn+Y9z8+8oyVVVoC+UwHO7+xqzArDBck=; b=edOYCSYZa33csLvdqnX8kzaKAzzyZHxeNaDGzd12znf4ApO9prKNNeXHnPFNlqYL4L lke2za8LZIKrgwmVoFkD1X3p3meJMoMIK8el41l23z/Jak98vu+oL5voIguI/A8U3fs2 Hx1NosOmU+ro5/bn0jQtbNvmcHkZt0SyEwIAMEiZhAlnuT68Jog9CLXqNg3X9bVg1iRq 2E/1DD6aMEhhBsUeq4LgTnoc0xirRSoo2889B2ylpC/M6dx4PFF7bEajSYugd9q5tocQ lz3NsowSJenOqAhrMqlykZca2vbcaOXOBpaaMSFhrr6f6VA4h2xySf03n2d9c6E4kTib ntRw== X-Gm-Message-State: AEkooutTDfkHXvR7k6mBpH2GVJeU4DUsehlJfo8QkGfE/H4B1hgAlH8E3NgzdpedP3us2Q== X-Received: by 10.98.81.1 with SMTP id f1mr129142054pfb.35.1470337415163; Thu, 04 Aug 2016 12:03:35 -0700 (PDT) Received: from [10.7.3.210] ([50.250.250.45]) by smtp.gmail.com with ESMTPSA id e10sm22176266pay.39.2016.08.04.12.03.32 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 04 Aug 2016 12:03:33 -0700 (PDT) To: Ard Biesheuvel , steven.shi@intel.com, yonghong.zhu@intel.com, liming.gao@intel.com, jordan.l.justen@intel.com, edk2-devel@lists.01.org References: <1470300343-17287-1-git-send-email-ard.biesheuvel@linaro.org> From: Nicolas Owens Message-ID: <08b65ea6-3235-eb16-41bb-7f6bdcc42638@offblast.org> Date: Thu, 4 Aug 2016 12:03:31 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <1470300343-17287-1-git-send-email-ard.biesheuvel@linaro.org> 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:03:35 -0000 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit ard, i think you need to have R_X86_64_PLT32 case in WriteRelocations64. without that, i still hit the invalid relocation message. 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. > > 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 >