llvm dev - Sep 2016 - [lld][ELF] Addends adjustment for relocatable object

Hi,

Now in case of relocatable object generation LLD merges and copies
REL/RELA sections as is and does not touch any addends. But it is
incorrect. If we have a relocation which targets a section, we have to
adjust the relocation's addend to take in account that the section
might be merged with other ones.

Here is the reproduction script:

% cat t1.s
  .data
  .long 0
  .text
bar:
  movl $1, .data

% cat t2.s
  .data
  .long 0
  .text
foo:
  movl $1, .data

% as t1.s -o t1.o
% as t2.s -o t2.o

% lld -flavor gnu -r t1.o t2.o
% llvm-readobj -r a.out
    0x3 R_X86_64_32S .data 0x0
    0xE R_X86_64_32S .data 0x0

% ld -r t1.o t2.o
% llvm-readobj -r a.out
    0x3 R_X86_64_32S .data 0x0
    0xE R_X86_64_32S .data 0x4

Are there any plans to fix this problem? I think it is rather easy to
fix it for RELA sections, but the case is more complicated for REL
sections. IMHO an alternative solution would be not to merge sections
while generate a relocatable object.

-- 
Simon Atanasyan

Hello Simon,

Can I just check something with you? When I tried the example the
.data section symbols given in the llvm-readelf -r output are
different, one has an offset of 0 and one has an offset of 4 so the
addends don't need updating. In ld the section symbols both have the
same offset of 0 so the addends need updating. So I think the two
approaches are equivalent.

Have I misunderstood?

Peter

On 27 September 2016 at 08:28, Simon Atanasyan via llvm-dev
<llvm-dev at lists.llvm.org> wrote:
> Hi,
>
> Now in case of relocatable object generation LLD merges and copies
> REL/RELA sections as is and does not touch any addends. But it is
> incorrect. If we have a relocation which targets a section, we have to
> adjust the relocation's addend to take in account that the section
> might be merged with other ones.
>
> Here is the reproduction script:
>
> % cat t1.s
>   .data
>   .long 0
>   .text
> bar:
>   movl $1, .data
>
> % cat t2.s
>   .data
>   .long 0
>   .text
> foo:
>   movl $1, .data
>
> % as t1.s -o t1.o
> % as t2.s -o t2.o
>
> % lld -flavor gnu -r t1.o t2.o
> % llvm-readobj -r a.out
>     0x3 R_X86_64_32S .data 0x0
>     0xE R_X86_64_32S .data 0x0
>
> % ld -r t1.o t2.o
> % llvm-readobj -r a.out
>     0x3 R_X86_64_32S .data 0x0
>     0xE R_X86_64_32S .data 0x4
>
> Are there any plans to fix this problem? I think it is rather easy to
> fix it for RELA sections, but the case is more complicated for REL
> sections. IMHO an alternative solution would be not to merge sections
> while generate a relocatable object.
>
> --
> Simon Atanasyan
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev

You are right. LLD does not have this problem. Initially I bumped into
the MIPS specific bug related to GP relative relocations calculation.
I tried to make reproduction script as general as possible and
mistakenly make it too general. So now with your help I realized that
the problem solely affects MIPS.

On Tue, Sep 27, 2016 at 8:46 PM, Peter Smith <peter.smith at linaro.org>
wrote:
> Hello Simon,
>
> Can I just check something with you? When I tried the example the
> .data section symbols given in the llvm-readelf -r output are
> different, one has an offset of 0 and one has an offset of 4 so the
> addends don't need updating. In ld the section symbols both have the
> same offset of 0 so the addends need updating. So I think the two
> approaches are equivalent.
>
> Have I misunderstood?
>
> Peter
>
> On 27 September 2016 at 08:28, Simon Atanasyan via llvm-dev
> <llvm-dev at lists.llvm.org> wrote:
>> Hi,
>>
>> Now in case of relocatable object generation LLD merges and copies
>> REL/RELA sections as is and does not touch any addends. But it is
>> incorrect. If we have a relocation which targets a section, we have to
>> adjust the relocation's addend to take in account that the section
>> might be merged with other ones.
-- 
Simon Atanasyan