This is the mail archive of the
mailing list for the binutils project.
Re: R_X86_64_COPY bug
- From: Fredrick Prashanth John Berchmans <fredrickprashanth at gmail dot com>
- To: Alexander Ivchenko <aivchenk at gmail dot com>
- Cc: Suresh Siddha <sbsiddha 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 11:34:50 -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> <CALmL7E92MjbsXbou8T3w895G9ahtd1tvC2JwREwV9EzT4Px20Q at mail dot gmail dot com> <CACysShj5aH4pWZHjxj74-B7z8a8d_NTKUyEcN8DFJXxaCa5=6g at mail dot gmail dot com>
On Sat, Apr 6, 2013 at 1:49 AM, Alexander Ivchenko <email@example.com> wrote:
> Have you tried '-z nocopyrelocs' option for linker which tries to
> avoid COPY relocations?
nocopyreloc gives segfault :(
./test_misc.bin: Symbol `test_dynamic' causes overflow in R_X86_64_32 relocation
Segmentation fault (core dumped)
And also, as far as I understand, you can make
> your binary 'pie'
> 2013/4/6 Suresh Siddha <firstname.lastname@example.org>:
>> On Sat, Apr 6, 2013 at 12:13 AM, Alan Modra <email@example.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
>>> .align 4
>>> .type test_dynamic, @object
>>> .size test_dynamic, 4 # <===========
>>> .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