From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-io0-x22c.google.com (mail-io0-x22c.google.com [IPv6:2607:f8b0:4001:c06::22c]) (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 BD4231A1E11 for ; Sun, 31 Jul 2016 22:58:35 -0700 (PDT) Received: by mail-io0-x22c.google.com with SMTP id m101so177584860ioi.2 for ; Sun, 31 Jul 2016 22:58:35 -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:content-transfer-encoding; bh=nhP11jIj0YdH/wOMfix9nl3g6Dj+gn7d2Dn7bIeO2Q0=; b=WhHkt2gKg6hcLr0XtECGjSkN1wIBTrgO+7c09/H0bEhDANacc+0R6QJQ/EKMs97kkD +D79LA/qaudIR2HBUwoS8YAHJ9UZqmHuyeCozVkbYXUdM/DFgDAQG3scUc87UrUTNRph RoQyGd3yYLyTplYlaVT3wSiAELsUGL1BW2JAg= 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:content-transfer-encoding; bh=nhP11jIj0YdH/wOMfix9nl3g6Dj+gn7d2Dn7bIeO2Q0=; b=WFNmXgzhjIXq5DcYFG+Ujj2f4/GgNCYNRTTQDG7e8DSdVdzWNpobp9RfkFCw1175xa 7k3WG3pI6a0qUAcpNHUqf7utpPtHCw1M8RP00h1+YB1Ta0HBNBDuysNH5IJRyTDBvOi7 50DG/p39kgOZKuW947kT+D063o4hIwao1FZxveSl3S/Pj6US5hZVJnPMxUvRP+hvpBkO KUDdQ3KHkReKzbazFKV6DXeOU6lLZkM9nzn/vkjGr1BI7NTAsahXFgknjxAN/fS09J7q jsXbEohgqB1YpsEQnurqxL4qrZ14SwtmfJfCPm3t5yzIFrqwTwJU17wGmrLNPn98Kutk N0vQ== X-Gm-Message-State: AEkoouvf3TvgtjdjQeZnS94A3lIjKadEneDWj5QsCxTguAOWN2jcDTBC7oCe0cN0kht+3faMdKDnGk76iCBRlfNu X-Received: by 10.107.135.22 with SMTP id j22mr62373964iod.56.1470031114823; Sun, 31 Jul 2016 22:58:34 -0700 (PDT) MIME-Version: 1.0 Received: by 10.36.204.195 with HTTP; Sun, 31 Jul 2016 22:58:34 -0700 (PDT) In-Reply-To: <06C8AB66E78EE34A949939824ABE2B3103381AD8@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> From: Ard Biesheuvel Date: Mon, 1 Aug 2016 07:58:34 +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 05:58:36 -0000 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 1 August 2016 at 06:39, Shi, Steven wrote: >> > >> > That was not my point. With your code, how many >> > EFI_IMAGE_REL_BASED_DIR64 fixups are added to the .reloc section for >> > the GOT entry of 'n'? >> > >> > int n; >> > int f () { return n; } >> > int g () { return n; } >> > int h () { return n; } > > [Steven]: If the above global " n " need GOTPCREL type relocation. It sho= uld need only once EFI_IMAGE_REL_BASED_DIR64 fixups in my code. > Yes, I believe so. I think it would be possible to sort the .reloc section and eliminate duplicates, but doing this correctly is non-trivial in any case. >> >> 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 d= omain 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 gl= obal data and function references in the code." And these different level o= f indirection is implemented through GOT and PLT structure with different a= ddressing calculation pattern. The different calculation patterns are the d= ifferent relocation types which are defined by x86_64 ABI Table 4.9. We d= on't need worry about how compiler correctly generate code to work with the= se relocation types, we just need correctly understand their addressing cal= culation 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 i= n the relocation calculation pattern, but how to co-work with specific inst= ructions 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. > One important thing worthy to mention that our gcc link script (GccBase.l= ds) has forced the GOT related sections , e.g. '.got', '.got.plt' , into .t= ext section. So, all the GOT relocation fixup target .text section in fact. > > I find below article help me a lot to understand some PIC simple relocati= on types. Hope it also can help you. I wish Eli, the author of below articl= es, could be invited as one author of x86_64 ABI spec, which will surely ma= ke the spec be more readable to other domain developers. :) > Position Independent Code (PIC) in shared libraries > http://eli.thegreenplace.net/2011/11/03/position-independent-code-pic-in-= shared-libraries/ > Position Independent Code (PIC) in shared libraries on x64 > http://eli.thegreenplace.net/2011/11/11/position-independent-code-pic-in-= shared-libraries-on-x64 > >> >> All in all, I think supporting GOT based relocations is a can of >> worms, and I would prefer to get rid of them completely if we can >> (i.e., using hidden visibility even for LTO, I have a fix for that I >> will sent out separately) >> > [Steven]: I agree we should try to avoid generating complex relocation ty= pe code for Uefi. But to make Uefi code build more portable to various vers= ion compilers and linker, I think it is still necessary to support these GO= T based relocations. > I've tested the GenFw new relocation types support with both GCC5/GCC49 (= with default visibility) and CLANG38 in my branch in before. It can works. = I suggest we could just keep these code there for reference. > 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. --=20 Ard.