This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH x86_64] Optimize access to globals in "-fpie -pie" builds with copy relocations


On Wed, Dec 3, 2014 at 10:35 PM, H.J. Lu <hjl.tools@gmail.com> wrote:

>>>>>> It would probably help reviewers if you pointed to actual path
>>>>>> submission [1], which unfortunately contains the explanation in the
>>>>>> patch itself [2], which further explains that this functionality is
>>>>>> currently only supported with gold, patched with [3].
>>>>>>
>>>>>> [1] https://gcc.gnu.org/ml/gcc-patches/2014-09/msg00645.html
>>>>>> [2] https://gcc.gnu.org/ml/gcc-patches/2014-09/txt2CHtu81P1O.txt
>>>>>> [3] https://sourceware.org/ml/binutils/2014-05/msg00092.html
>>>>>>
>>>>>> After a bit of the above detective work, I think that new gcc option
>>>>>> is not necessary. The configure should detect if new functionality is
>>>>>> supported in the linker, and auto-configure gcc to use it when
>>>>>> appropriate.
>>>>>
>>>>> I think GCC option is needed since one can use -fuse-ld= to
>>>>> change linker.
>>>>
>>>> IMO, nobody will use this highly special x86_64-only option. It would
>>>> be best for gnu-ld to reach feature parity with gold as far as this
>>>> functionality is concerned. In this case, the optimization would be
>>>> auto-configured, and would fire automatically, without any user
>>>> intervention.
>>>>
>>>
>>> Let's do it.  I implemented the same feature in bfd linker on both
>>> master and 2.25 branch.
>>>
>>
>> +bool
>> +i386_binds_local_p (const_tree exp)
>> +{
>> +  /* Globals marked extern are treated as local when linker copy relocations
>> +     support is available with -f{pie|PIE}.  */
>> +  if (TARGET_64BIT && ix86_copyrelocs && flag_pie
>> +      && TREE_CODE (exp) == VAR_DECL
>> +      && DECL_EXTERNAL (exp) && !DECL_WEAK (exp))
>> +    return true;
>> +  return default_binds_local_p (exp);
>> +}
>> +
>>
>> It returns true with -fPIE and false without -fPIE.  It is lying to compiler.
>> Maybe legitimate_pic_address_disp_p is a better place.

Agreed.

> Something like this?

Yes.

OK, if Jakub doesn't have any objections here. Please also add
Sriraman as author to ChangeLog entry.

Thanks,
Uros.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]