On Wed, Dec 3, 2014 at 5:47 AM, H.J. Lu <hjl.to...@gmail.com> wrote:
> On Tue, Dec 2, 2014 at 12:01 PM, Uros Bizjak <ubiz...@gmail.com> wrote:
>> On Tue, Dec 2, 2014 at 8:40 PM, H.J. Lu <hjl.to...@gmail.com> wrote:
>>> On Tue, Dec 2, 2014 at 11:19 AM, Uros Bizjak <ubiz...@gmail.com> wrote:
>>>> Hello!
>>>>
>>>>> Ping.
>>>>>> Ping.
>>>>>>> Ping.
>>>>>>>> Ping.
>>>>
>>>> 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.

-- 
H.J.

Reply via email to