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, Feb 4, 2015 at 10:31 AM, Jakub Jelinek <jakub@redhat.com> wrote:
> On Wed, Feb 04, 2015 at 10:27:34AM -0800, Sriraman Tallam wrote:
>> On Tue, Feb 3, 2015 at 5:16 PM, H.J. Lu <hjl.tools@gmail.com> wrote:
>> > On Tue, Feb 3, 2015 at 2:19 PM, Jakub Jelinek <jakub@redhat.com> wrote:
>> >> On Tue, Feb 03, 2015 at 02:03:14PM -0800, H.J. Lu wrote:
>> >>> So we aren't SYMBOL_REF_EXTERNAL_P nor
>> >>> SYMBOL_REF_LOCAL_P.  What do we reference?
>> >>
>> >> That is reasonable.  There is no guarantee the extern weak symbol is local,
>> >> it could very well be non-local.  All that you know about the symbols is
>> >> that its address is non-NULL in that case.
>> >>
>> >
>> > This may be true for shared library.  But it isn't true for PIE:
>>
>>
>> Also, gcc and g++ are inconsistent about something even more simple:
>>
>> $ cat x.c
>>
>> int a;
>>
>> int main() {
>>   printf("%d\n", a);
>> }
>>
>> With gcc -fPIE x.c
>> SYMBOL_REF_LOCAL_P(op0) = false
>>
>> With g++ -fPIE x.c
>> SYMBOL_REF_LOCAL_P(op0) = true
>
> Try -fno-common for C and you'll get the same result as in C++.
> Common symbols can't be considered SYMBOL_REF_LOCAL_P, they might resolve
> to a non-common symbol from different TU.

Common symbol should be resolved locally for PIE.


-- 
H.J.


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