From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-it0-x22b.google.com (mail-it0-x22b.google.com [IPv6:2607:f8b0:4001:c0b::22b]) (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 366321A1E11 for ; Mon, 1 Aug 2016 01:00:16 -0700 (PDT) Received: by mail-it0-x22b.google.com with SMTP id u186so238664669ita.0 for ; Mon, 01 Aug 2016 01:00:16 -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 :cc; bh=qJgxo8nXUYs1DjHWPDyhPZzPQb8GYDtglJDyn+iUh1o=; b=QI45VCHHEtrcTUHopSFrVjl24p8xawv2oPbuLVaYey7i4tImPi49DK7lAs2T/uphM6 xBC9GsZrFbiB4JZAWbW2uz78hzQVtBAj6xoEq5gj4aGSepPEnF/3kJG68xztkhgv8ZUD uane8Q8ErzYoVHbvBaBjjS8xFEiLbuCK4F4BE= 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:cc; bh=qJgxo8nXUYs1DjHWPDyhPZzPQb8GYDtglJDyn+iUh1o=; b=CUBdQ3pDJXZFcd4pAKGJmui0ZH4gMPjLBam6twBEkfZjflojDX+hCWchCWrP96OZyr xzgZKVhDbzkRfqps5XsFcG1VPiUcjRwdOKaEwh7sna5fGD2Jcf5BPvFpOU2qichJj7a8 y15X3qbAdMdTTrptLg0cFstARmquhHR8PcO0yy7pearfiWJInaXInzP1a/K2Ns7XiR6u mcjIF4qswX0Ss+lCGpwIyGJQYV9odtJmq/w8ddtJFgloHxw1nd4uiX69GkmCwOd8QWE2 PM6qoRgeX9rGIEbw6OMbmnkz1dAxvlZhszuEHfM1G1DkpnOlcOw32qW0DWicQevTTXFg m2Eg== X-Gm-Message-State: AEkoout2jRz6uNWRS8JxHkWCXar20WiOqVQFjbrH6L5zkAi8LMI2oaHZbT7iZUny1q2G06nspHpEoxnN/mq08Wq1 X-Received: by 10.36.86.134 with SMTP id o128mr59583711itb.5.1470038415557; Mon, 01 Aug 2016 01:00:15 -0700 (PDT) MIME-Version: 1.0 Received: by 10.36.204.195 with HTTP; Mon, 1 Aug 2016 01:00:15 -0700 (PDT) In-Reply-To: <06C8AB66E78EE34A949939824ABE2B31033824FA@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> From: Ard Biesheuvel Date: Mon, 1 Aug 2016 10:00:15 +0200 Message-ID: To: "Shi, Steven" Cc: "Kinney, Michael D" , "Justen, Jordan L" , edk2-devel-01 , "afish@apple.com" , "Gao, Liming" 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 08:00:16 -0000 Content-Type: text/plain; charset=UTF-8 On 1 August 2016 at 09:54, Shi, Steven wrote: >> On 1 August 2016 at 09:19, Shi, Steven > wrote: >> >> >> >> >> >> The fact that it works does not make it safe. Having multiple fixups >> >> >> for the same symbol in the .reloc section is a problem, and so is >> >> >> reapplying GOTPCRELX to places where the original instruction has >> been >> >> >> replaced by the linker. >> >> >> >> >> > [Steven]: I still don't understand why there will be multiple fixups for the >> >> same symbol in the .reloc section? >> >> > >> >> >> >> Remember this example >> >> >> >> >> > int n; >> >> >> > int f () { return n; } >> >> >> > int g () { return n; } >> >> >> > int h () { return n; } >> >> >> >> If every 'return n' results in a GOTPCREL relocation, how are you >> >> going to make sure that the GOT entry for 'n' is only fixed up a >> >> single time? >> > >> > [Steven]: the 'return n' will not result in relocation, but the 'int n' will result >> in the relocation in GOT. The three 'return n' will point to the same 'int n' >> relocation item. So, we need only fixup 'int n' once, all three 'return n' will >> use the correct global 'n' value. >> >> Every 'return n' will result in a GOTPCREL relocation against n. And >> your code emits a relocation for the GOT entry every time. >> > [Steven]: I don't think so. please give a real case and offer its source code to prove " Every 'return n' will result in a GOTPCREL relocation against n ". > Compiling the code above using gcc -c -O -fpic /tmp/pie.c -o pie.o and dumping it using readelf -r pie.o gives me Relocation section '.rela.text' at offset 0x250 contains 3 entries: Offset Info Type Sym. Value Sym. Name + Addend 000000000003 000a0000002a R_X86_64_REX_GOTP 0000000000000004 n - 4 00000000000d 000a0000002a R_X86_64_REX_GOTP 0000000000000004 n - 4 000000000017 000a0000002a R_X86_64_REX_GOTP 0000000000000004 n - 4 ... -- Ard.