From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-it0-x22e.google.com (mail-it0-x22e.google.com [IPv6:2607:f8b0:4001:c0b::22e]) (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 56FFA1A1E11 for ; Sun, 31 Jul 2016 23:43:09 -0700 (PDT) Received: by mail-it0-x22e.google.com with SMTP id u186so236791540ita.0 for ; Sun, 31 Jul 2016 23:43:09 -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=KHcNe3Kh3Nsfa1ylulvtBkXPyQdXIlq1CzetL8DqdM4=; b=VNvvqi4WV9FhDGljmouQcLKlJLaaRgl/u8oH/Dh2XtxFf7SOqCFtueRZysp398c/Np Kn8zUAanGIMz2WuIrWme61ykKlxp5hx8HVFZFl8S/4BQpJ/UvC0TJXLGe8zLRpCTB7GA V6sFhKHqJg+8IQZSF9p2zQ7hU/rVVwrUtDRlM= 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=KHcNe3Kh3Nsfa1ylulvtBkXPyQdXIlq1CzetL8DqdM4=; b=jNMPoqxiVziaF/MzOQ3V+yo1A/E9ZcVOtpxUIPYT2K9BSkVKzoEeEAS7koNFrR4tuw yRyP3yapx2uvR9V8nNF9HR34MynSasaOFOWJSP1aWkDZyyTEpyjbBiIjS27AVCaOHkYv kgtfRrsbAPfX0gvmBP+PBFLBWG0t4Xq99HzROugmOY1d1zcEkwu9AwvYmHIsE4fLLkYX XNZYqFW3/HFvsoFoqBVzdX4ZND99tf9MtTep3BpM6vRjTz60iT7RfctvZ6wiEI1KDHWs yiZ71DCUREZWvI3Bjnfm7P1cLq7TauJlqX/kBJdhleeAk+rfPZwyr+TJR9I1Krei8vru 88rA== X-Gm-Message-State: AEkoouvZwUy7ehoMYO4Ihda718e5aCUcXuDcVxfMibOU3iT+NGuGoe2EOvn9qdf+nQ0VaH4jbO6UxGKXN8N6pcKc X-Received: by 10.36.25.144 with SMTP id b138mr6810918itb.29.1470033788569; Sun, 31 Jul 2016 23:43:08 -0700 (PDT) MIME-Version: 1.0 Received: by 10.36.204.195 with HTTP; Sun, 31 Jul 2016 23:43:08 -0700 (PDT) In-Reply-To: <06C8AB66E78EE34A949939824ABE2B3103381BF3@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> From: Ard Biesheuvel Date: Mon, 1 Aug 2016 08:43:08 +0200 Message-ID: To: "Shi, Steven" Cc: edk2-devel-01 , "Gao, Liming" , "afish@apple.com" , "Justen, Jordan L" , "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 06:43:09 -0000 Content-Type: text/plain; charset=UTF-8 On 1 August 2016 at 08:13, Shi, Steven wrote: >> >> >> >> I am also concerned about the GOTPCRELX/REX_GOTPCRELX relocations. >> >> Reading the x86_64 ABI docs, it appears that these may refer to >> >> instructions that have been modified by the linker. In that case, how >> >> do we deal with the relocation? Also, according to the doc, mov >> >> instructions may be emitted by the linker in some cases that are only >> >> valid in the lowest 2 GB of the address space. >> >> >> > [Steven]: Frankly to say, the x86_64 ABI docs is only good for compiler >> domain developer and not very good for other domain developers to >> understand it. >> > My overall understanding for these different relocation type is like this: >> compiler generate PIC code with different "level of indirection to all global >> data and function references in the code." And these different level of >> indirection is implemented through GOT and PLT structure with different >> addressing calculation pattern. The different calculation patterns are the >> different relocation types which are defined by x86_64 ABI Table 4.9. We >> don't need worry about how compiler correctly generate code to work with >> these relocation types, we just need correctly understand their addressing >> calculation pattern. >> > >> > The GOTPCRELX/REX_GOTPCRELX has the same calculation definition in >> x86_64 ABI Table 4.9 as "G + GOT + A - P". So, I assume their difference is not >> in the relocation calculation pattern, but how to co-work with specific >> instructions to finish these calculation in a hardware optimized way. >> > >> >> No, that is not what these are for. The special types mark >> instructions that can be converted by the linker into simpler >> sequences if the symbol turns out to be in the same module. From the >> doc: >> >> mov foo@GOTPCREL(%rip), %reg >> >> could be converted by the linker into >> >> lea foo(%rip), %reg >> >> if the reference to 'foo' is satisfied by a non-preemptible local >> definition. This is a useful optimization, since it eliminates a >> memory load. The problem is that we cannot recalculate such >> relocations in GenFw without checking whether the linker has applied >> this optimization or not. >> > [Steven]: Do you mean the linker will apply above optimization but not remove the original GOTPCREL item? It sounds like a severe linker bug. > I checked quickly, and it appears the linker does the right thing here, i.e., it performs the optimization and also modifies the relocation emitted into the .rela.text section So this: .globl bar .type bar, @function bar: mov foo@GOTPCREL(%rip), %eax ret .globl foo foo: .quad 0 compiles into /tmp/pie.o: file format elf64-x86-64 Disassembly of section .text: 0000000000000000 : 0: 8b 05 00 00 00 00 mov 0x0(%rip),%eax # 6 2: R_X86_64_GOTPCRELX foo-0x4 6: c3 retq 0000000000000007 : ... but after linking (ld -o /tmp/pie -e bar -q /tmp/pie.o) /tmp/pie: file format elf64-x86-64 Disassembly of section .text: 00000000004000b0 : 4000b0: 8d 05 01 00 00 00 lea 0x1(%rip),%eax # 4000b7 4000b2: R_X86_64_PC32 foo-0x4 4000b6: c3 retq 00000000004000b7 : ... >> >> 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?