From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-it0-x22f.google.com (mail-it0-x22f.google.com [IPv6:2607:f8b0:4001:c0b::22f]) (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 259DF1A1E11 for ; Mon, 1 Aug 2016 00:25:46 -0700 (PDT) Received: by mail-it0-x22f.google.com with SMTP id j124so161536648ith.1 for ; Mon, 01 Aug 2016 00:25:46 -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=wGUKVaMLszuCSkd8xuCgF7suRKRMMfXMIZq1pPYu4eQ=; b=EZKwmnpP80HARQlhRcvWbAvGP2uNkGbMGpaVg5Gw2Y5Fo12wxz5fQ4uZNPgVVKpCNa kp6LwL0Y+K4FBZzY/EYYGu5MWr1ASQ7+ljljf9lE19btW6UROVfiJFaxQqQ9pFB8C/uo QP5599WJWh34lCGAkSK+8kCxU3uladB0t2Z5I= 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=wGUKVaMLszuCSkd8xuCgF7suRKRMMfXMIZq1pPYu4eQ=; b=XkzznmuqeKcfI+HvpkPYqWIhwYdG45cQ1MrvNbtx3DSfoh+6dqMl1AldGVJNVY21WD IiH5Q1MeMO8zn2HArda0UdtefmYb+EheZdLNyQd29RGu6WOGuz1u9lSziUQ2hDQQ7CPJ nhoWWopqgHWamABmnbvnF8j9vIeAoZWsNLuVBmrxEsuODotWOSLG0XGRDuvYjuGB+uul oHbUm3KDASAifpQ7GttFZkA5u3DLPSK09UVdL1ujzor54H1RU9uJEIkzET6urfXZRY7w gZ38q4tReDB0gD5WksMRAp5ejU6Kznv/maeEAH9AXHWejUl12SCybASdwEvQY4aiXd1x 9VYg== X-Gm-Message-State: AEkoouvh72ZldRgQD5n6t+8Zy7FeSja2wjaDJn18H7MeZnxISoI7hfCNOUwztEpzOCDKKUTs3dTYWe1M71Vygrrx X-Received: by 10.36.107.211 with SMTP id v202mr53835354itc.51.1470036345411; Mon, 01 Aug 2016 00:25:45 -0700 (PDT) MIME-Version: 1.0 Received: by 10.36.204.195 with HTTP; Mon, 1 Aug 2016 00:25:44 -0700 (PDT) In-Reply-To: <06C8AB66E78EE34A949939824ABE2B3103382483@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> From: Ard Biesheuvel Date: Mon, 1 Aug 2016 09:25:44 +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 07:25:46 -0000 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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 bee= n >> >> replaced by the linker. >> >> >> > [Steven]: I still don't understand why there will be multiple fixups f= or 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' w= ill 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 thr= ee '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. BTW, the 'int n' relocation type in your code on X64 should be R_X86_64_GLOB_DAT > R_X86_64_GLOB_DAT is a dynamic relocation type. These are only emitted when linking a shared object or a PIE executable, which I would like to avoid as well. The problem with PIE executables is that the .rela.xxx sections emitted for each section, and the single .rela section containing the dynamic relocations overlap with each other, i.e., places containing absolute symbol addresses in the binary will appear in both, and emitting reloc fixups for all relocations will result in duplicates. > You can see the 'int myglob' in Eli's example in http://eli.thegreenplace= .net/2011/11/03/position-independent-code-pic-in-shared-libraries/. The 'in= t myglob' is same as your 'int n' example. > > int myglob =3D 42; > int ml_func(int a, int b) > { > return myglob + a + b; > } > Yes, and every reference to 'myglob' will result in a GOTPCREL relocation. We must not emit a fixup for myglob every time.