From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-it0-x234.google.com (mail-it0-x234.google.com [IPv6:2607:f8b0:4001:c0b::234]) (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 8715A1A1E0A for ; Mon, 1 Aug 2016 03:46:57 -0700 (PDT) Received: by mail-it0-x234.google.com with SMTP id f6so242651332ith.1 for ; Mon, 01 Aug 2016 03:46:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-transfer-encoding; bh=PW2sZfCZaBFdAKgRberQW6IQLt+otNYKh5V34iEocz8=; b=Oy7nqP+wmh8G3bfTdn/mtzCYsjXHbFUG+QUWfEUS7TntLbVRAvXr6MvTF7qIx3dMfZ RMFtvauKXE5huYXkr3LWwyUS/BepMLv4h6kB38WCN0CVGN2FaCxQe6f/UdNK6EaC1zGS NBNJPPEB7I1VTzuKFfWso+WMqB6BBov8WuKBU= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:content-transfer-encoding; bh=PW2sZfCZaBFdAKgRberQW6IQLt+otNYKh5V34iEocz8=; b=UPzwz6/IHEx49qv5Yq3kTXLB0tf/1b1zzdd6qYERrV1hjZkCS6wO5EL5D4J1eh0nIp 7vMyOnZCKojon+JbAXSHu8RFYlHFoN3LgCsCcLwe46TpG/og2DavTt8APl4yXe4V9FSX wb2ubSrSOTl/ShbuiJXhjkw1eILDchzoe94Uq+3F19JbTF8+bl1/Tum8oMTzEiVM2wHL eMC1ZJGVgJtua609e3CgryTG5pxsxdl7uUGv6DBqiJZ0cujSCBVLLgp/P7hbgJYvdRiC fGp8wvNTtqOF44c3kTzXpWwOJ1pBZw875X2YV5AcxVyzuxRCOv7AaRed8SVMI4EqzGFL p6WQ== X-Gm-Message-State: AEkoouu7JozHLH3JjF6ki1QgATwwrfsqjERF9Nfo/LntEHtuNW5i7pqgJF+Aqy6nlJBGdlWGHECAZ1G1JvQvhver X-Received: by 10.36.7.209 with SMTP id f200mr56155151itf.29.1470048416787; Mon, 01 Aug 2016 03:46:56 -0700 (PDT) MIME-Version: 1.0 Received: by 10.36.204.195 with HTTP; Mon, 1 Aug 2016 03:46:56 -0700 (PDT) In-Reply-To: <06C8AB66E78EE34A949939824ABE2B310338275F@shsmsx102.ccr.corp.intel.com> References: <1467967364-11556-1-git-send-email-steven.shi@intel.com> <1467967364-11556-3-git-send-email-steven.shi@intel.com> <06C8AB66E78EE34A949939824ABE2B3103381245@shsmsx102.ccr.corp.intel.com> <06C8AB66E78EE34A949939824ABE2B31033813C8@shsmsx102.ccr.corp.intel.com> <06C8AB66E78EE34A949939824ABE2B3103381AD8@shsmsx102.ccr.corp.intel.com> <06C8AB66E78EE34A949939824ABE2B3103381BF3@shsmsx102.ccr.corp.intel.com> <06C8AB66E78EE34A949939824ABE2B3103382483@shsmsx102.ccr.corp.intel.com> <06C8AB66E78EE34A949939824ABE2B31033824FA@shsmsx102.ccr.corp.intel.com> <06C8AB66E78EE34A949939824ABE2B31033825EE@shsmsx102.ccr.corp.intel.com> <06C8AB66E78EE34A949939824ABE2B31033826FE@shsmsx102.ccr.corp.intel.com> <06C8AB66E78EE34A949939824ABE2B310338275F@shsmsx102.ccr.corp.intel.com> From: Ard Biesheuvel Date: Mon, 1 Aug 2016 12:46:56 +0200 Message-ID: To: "Shi, Steven" , edk2-devel-01 , "Gao, Liming" , "afish@apple.com" , Jordan Justen , "Kinney, Michael D" Subject: Re: [PATCH v2 2/7] BaseTools-GenFw:Add new x86_64 Elf relocation types for PIC/PIE code 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: Mon, 01 Aug 2016 10:46:57 -0000 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable (adding back our friends on cc) On 1 August 2016 at 12:36, Shi, Steven wrote: >> On 1 August 2016 at 12:16, Shi, Steven wrote: >> >> OK, another example: >> >> >> >> pie.s: >> >> >> >> .globl foo >> >> foo: >> >> pushq n@GOTPCREL(%rip) >> >> popq %rax >> >> ret >> >> >> >> .globl bar >> >> bar: >> >> pushq n@GOTPCREL(%rip) >> >> popq %rax >> >> ret >> >> >> >> .globl n >> >> n: >> >> .quad 0 >> >> >> >> compile and link using >> >> >> >> gcc -c -o pie.o /tmp/pie.s >> >> ld -q -o pie pie.o -e foo >> >> >> >> gives me >> >> >> >> Relocation section '.rela.text' at offset 0x260 contains 2 entries: >> >> Offset Info Type Sym. Value Sym. Na= me + Addend >> >> 0000004000b2 000700000009 R_X86_64_GOTPCREL 00000000004000be >> n - >> >> 4 >> >> 0000004000b9 000700000009 R_X86_64_GOTPCREL 00000000004000be >> n - >> >> 4 >> >> >> >> Here, pie is a fully linked binary. >> >> >> > [Steven]: In this example, there are two R_X86_64_GOTPCREL relocation >> address in the .text section need to fix up with same symbol runtime add= ress, >> these two relocation addresses are not same, and every relocation addres= s >> will be fixed up once. I don't see the problem of "Having multiple fixup= s for >> the same symbol in the .reloc section", and current GenFw code should h= as >> no problem on this example. >> > >> >> How many times will your code call CoffAddFixup() for the address of n? > [Steven]: My understanding is the n address (6000c8) is not a GOTPCREL re= location in .text section, but the 4000b2 and 4000b2 are GOTPCREL relocatio= n in .text section. My CoffAddFixup() will only call twice for 4000b2 and 4= 000b2, but not for n address (6000c8). > > Disassembly of section .text: > > 00000000004000b0 : > 4000b0: ff 35 12 00 20 00 pushq 0x200012(%rip) # 60= 00c8 > 4000b6: 58 pop %rax > 4000b7: c3 retq > > 00000000004000b8 : > 4000b8: ff 35 0a 00 20 00 pushq 0x20000a(%rip) # 60= 00c8 > 4000be: 58 pop %rax > 4000bf: c3 retq > > 00000000004000c0 : > ... > CoffAddFixup() must be used for absolute symbol references only. These instructions contain relative symbol references, which are recalculated in WriteSections64(). The only absolute symbol reference is the GOT entry for 'n', and your code (in WriteRelocations64()) calculates the address of the GOT entry (which is always in .text BTW) and adds a fixup for it, i.e., + CoffAddFixup( + (UINT32)(UINTN)((UINT64) mCoffSectionsOffset[RelShdr->sh_info] + GoTPcRelPtrOffset), + EFI_IMAGE_REL_BASED_DIR64); This code adds a fixup to the PE/COFF .reloc section for the GOT entry containing the address of 'n', and the instructions perform a IP relative load of the contents of the GOT entry to retrieve the address of 'n'. By adding two fixups, the PE/COFF loader will apply the load offset twice, resulting in an incorrect value. --=20 Ard.