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

[Rafael Espíndola via llvm-dev]

Agreed, handling SHF_MERGE as a regular section is probably the right
thing to do for -r.

Cheers,
Rafael


On 29 September 2016 at 10:05, Peter Smith via llvm-dev
<llvm-dev at lists.llvm.org> wrote:
> My  understanding is that SHF_MERGE permits but does not require a
> linker to merge identical entries, if they aren't merged they end up
> looking like data sections. So I think option 1 should work without
> problems.
>
> Peter
>
> On 28 September 2016 at 22:54, Rui Ueyama <ruiu at google.com> wrote:
>> On Wed, Sep 28, 2016 at 10:49 PM, Simon Atanasyan <simon at atanasyan.com>
>> wrote:
>>>
>>> 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.
>>
>>
>> I'd vote for 1. There might be a corner case that wouldn't work with that
>> approach (maybe kernel modules?) though.
>>
>>> 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
>>
>>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev