On Tue, Feb 3, 2015 at 1:20 PM, Sriraman Tallam <tmsri...@google.com> wrote:
> On Tue, Feb 3, 2015 at 11:36 AM, Jakub Jelinek <ja...@redhat.com> wrote:
>> 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.
>
> Thanks for clarifying.
>
>> You can only optimize weak vars if there is some weak definition in the
>> current TU.
>
> Would this be fine then? Replace !SYMBOL_REF_WEAK (op0) with
>
> !(SYMBOL_REF_WEAK (op0) && SYMBOL_REF_EXTERNAL_P (op0))
>
The full condition is:
&& (SYMBOL_REF_LOCAL_P (op0)
|| (HAVE_LD_PIE_COPYRELOC
&& flag_pie
&& !SYMBOL_REF_WEAK (op0)
&& !SYMBOL_REF_FUNCTION_P (op0)))
If the weak op0 is defined in the current TU, shouldn't
SYMBOL_REF_LOCAL_P (op0) be true for PIE?
--
H.J.
