This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH x86_64] Optimize access to globals in "-fpie -pie" builds with copy relocations
- From: Jakub Jelinek <jakub at redhat dot com>
- To: Sriraman Tallam <tmsriram at google dot com>
- Cc: "H.J. Lu" <hjl dot tools at gmail dot com>, Uros Bizjak <ubizjak at gmail dot com>, "gcc-patches at gcc dot gnu dot org" <gcc-patches at gcc dot gnu dot org>
- Date: Tue, 3 Feb 2015 20:36:15 +0100
- Subject: Re: [PATCH x86_64] Optimize access to globals in "-fpie -pie" builds with copy relocations
- Authentication-results: sourceware.org; auth=none
- References: <CAFULd4aMopCHZHTWa3V=6-CwVLq1grorwRqT7yCaOfpLWYZibw at mail dot gmail dot com> <CAMe9rOok=sUB=OVdFNt369gkpNWxVgzQKjeDVQT96SrSNRS=Vw at mail dot gmail dot com> <CAFULd4Z=WaenYMr=Ke1QLQAq4bVQpkOD_Wt3nW4w9F71fuaPAw at mail dot gmail dot com> <CAMe9rOpXge0X3Dz0OvnkWw1Q9HRPmNAFhYphVuquZj856J_RXQ at mail dot gmail dot com> <CAMe9rOr6BsvSgOtM2K+JfTgLktnTa19YFrfRUdRQpRPjDjOdmg at mail dot gmail dot com> <CAMe9rOpXupztWPgTWAxGx7yP7aynAjYoJbh-5L+wJ3S=qk8CvQ at mail dot gmail dot com> <CAFULd4aTkv0wjuqZMGCmYPiGJ50tLqWtf+-V0e3U5bFUj2Gfng at mail dot gmail dot com> <CAMe9rOpkZZmuhL_rqYrAE6wx6u7QYWe-DjuKp11u5wPh1dGztA at mail dot gmail dot com> <CAAs8Hmw0-+jN9BKwPB2BkGhTZwrc9V3zsAW2QTCuKnZKz7NVAQ at mail dot gmail dot com>
- Reply-to: Jakub Jelinek <jakub at redhat dot com>
On Tue, Feb 03, 2015 at 11:25:38AM -0800, Sriraman Tallam wrote:
> This was the original patch to i386.c to let global accesses take
> advantage of copy relocations and avoid the GOT.
>
>
> @@ -13113,7 +13113,11 @@ legitimate_pic_address_disp_p (rtx disp)
> return true;
> }
> else if (!SYMBOL_REF_FAR_ADDR_P (op0)
> - && SYMBOL_REF_LOCAL_P (op0)
> + && (SYMBOL_REF_LOCAL_P (op0)
> + || (HAVE_LD_PIE_COPYRELOC
> + && flag_pie
> + && !SYMBOL_REF_WEAK (op0)
> + && !SYMBOL_REF_FUNCTION_P (op0)))
> && ix86_cmodel != CM_LARGE_PIC)
>
> I do not understand here why weak global data access must go through
> the GOT and not use copy relocations. Ultimately, there is only going
> to be one copy of the global either defined in the executable or the
> shared object right?
>
> Can we remove the check for SYMBOL_REF_WEAK?
So, what will then happen if the weak undef symbol isn't defined anywhere?
In non-PIE binaries that is fine, the linker will store 0.
But in PIE binaries, the 0 would be biased by the PIE load bias and thus
wouldn't be NULL.
You can only optimize weak vars if there is some weak definition in the
current TU.
Jakub