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

[Simon Atanasyan via llvm-dev]

Initial issue is related to R_MIPS_GPREL16/32 relocations. When we
calculate such relocations we need to know _gp symbol's value. This
value might come from different sources. Usually we setup it using
constant offset from the .got section. Also it might be defined by a
linker script. And in rare but possible case it comes from .reginfo /
.MIPS.options sections.

Got example, GNU bfd linker has the following code to adjust
_gp-relative relocation addends:

 rel->r_addend += _bfd_get_gp_value (input_bfd);
 rel->r_addend -= _bfd_get_gp_value (output_bfd);

But I think we can escape to implement the same adjustments in LLD if
we do not support non-zero gp-value in the .reginfo / .MIPS.options
sections in input object files. We can get such files if somebody
produce a relocatable object file by bfd/gold linkers and attempt to
link this file using lld. It seems to be an uncommon case. To notify a
user lld might show an error in that case.

BTW it looks like there is another problem with relocation addend
adjustment in case of relocatable object generation. I did not
investigate it thoroughly though. Suppose we have a SHF_MERGE section
with two "equal" entries and a relocation which points to the second
entry using section+addend. Now we merge such sections even if we
generate a relocatable object. In that case we write reduced SHF_MERGE
section with the only entry. But the relocation still points to the
removed second entry and in fact points out of the section border.
Please correct me if I miss something.

I think we can fix that by the following way:
1. Do not try to merge SHF_MERGE sections if Config->Relocatable is true.
2. Do not group such sections together or group sections with the same
SHF_STRINGS / sh_entsize parameters.
3. Keep SHF_STRINGS flag and sh_entsize value when writing the
sections. In that case a linker will be able to merge/reduce such
sections later when it links a relocatable object to get DSO or
executable file.

On Wed, Sep 28, 2016 at 11:41 PM, Rui Ueyama <ruiu at google.com> wrote:
> Why this is MIPS-specific issue? Do you mean MIPS is the only architecture
> that uses both REL and RELA?
>
> On Tue, Sep 27, 2016 at 1:32 PM, Simon Atanasyan <simon at atanasyan.com>
> wrote:
>>
>> 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.

-- 
Simon Atanasyan