This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
Re: R_X86_64_COPY bug
- From: Alexander Ivchenko <aivchenk at gmail dot com>
- To: Suresh Siddha <sbsiddha at gmail dot com>
- Cc: Fredrick Prashanth John Berchmans <fredrickprashanth at gmail dot com>, binutils at sourceware dot org, hjl dot tools at gmail dot com, nasuku at yahoo dot com
- Date: Sat, 6 Apr 2013 12:49:23 +0400
- Subject: Re: R_X86_64_COPY bug
- References: <CACwgvgW5SNsXL2vND_qhgqO7RRsHwKyk+N-q5sTakeC9vwV0BA at mail dot gmail dot com> <20130406071305 dot GD3208 at bubble dot grove dot modra dot org> <CALmL7E92MjbsXbou8T3w895G9ahtd1tvC2JwREwV9EzT4Px20Q at mail dot gmail dot com>
Have you tried '-z nocopyrelocs' option for linker which tries to
avoid COPY relocations? And also, as far as I understand, you can make
your binary 'pie'
2013/4/6 Suresh Siddha <sbsiddha@gmail.com>:
> On Sat, Apr 6, 2013 at 12:13 AM, Alan Modra <amodra@gmail.com> wrote:
>> On Fri, Apr 05, 2013 at 09:29:09PM -0700, Fredrick Prashanth John Berchmans wrote:
>>> Dear binutils developers,
>>>
>>> We are seeing a issue with copy relocation semantics in ld.
>>>
>>> A struct with zero length array is defined in a shared library.
>>> Because of copy relocation semantics, any binary linking with that
>>> library sees those elements as zero initialized.
>>>
>>> We saw this bug also on ARM with R_ARM_COPY.
>>
>> This is not a bug in gas or ld. gcc is sizing the struct incorrectly.
>>
>> .globl test_dynamic
>> .data
>> .align 4
>> .type test_dynamic, @object
>> .size test_dynamic, 4 # <===========
>> test_dynamic:
>> .long 6
>> .long 1
>> .long 2
>> .long 3
>> .long 4
>> .long 5
>> .long 6
>
> Thanks for the quick response. Is there any way we can avoid copy
> relocations for these problematic types? We tried even giving the
> attribute of protected visibility. And it doesn't seem to help.
>
> -Suresh Siddha