This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
Re: R_X86_64_COPY bug
- From: Suresh Siddha <sbsiddha at gmail dot com>
- To: Fredrick Prashanth John Berchmans <fredrickprashanth at gmail dot com>, binutils at sourceware dot org, hjl dot tools at gmail dot com, sbsiddha at gmail dot com, nasuku at yahoo dot com
- Date: Sat, 6 Apr 2013 00:30:10 -0700
- 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>
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