<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Wed, Sep 28, 2016 at 10:49 PM, Simon Atanasyan <span dir="ltr"><<a href="mailto:simon@atanasyan.com" target="_blank">simon@atanasyan.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Initial issue is related to R_MIPS_GPREL16/32 relocations. When we<br>
calculate such relocations we need to know _gp symbol's value. This<br>
value might come from different sources. Usually we setup it using<br>
constant offset from the .got section. Also it might be defined by a<br>
linker script. And in rare but possible case it comes from .reginfo /<br>
.MIPS.options sections.<br>
<br>
Got example, GNU bfd linker has the following code to adjust<br>
_gp-relative relocation addends:<br>
<br>
┬árel->r_addend += _bfd_get_gp_value (input_bfd);<br>
┬árel->r_addend -= _bfd_get_gp_value (output_bfd);<br>
<br>
But I think we can escape to implement the same adjustments in LLD if<br>
we do not support non-zero gp-value in the .reginfo / .MIPS.options<br>
sections in input object files. We can get such files if somebody<br>
produce a relocatable object file by bfd/gold linkers and attempt to<br>
link this file using lld. It seems to be an uncommon case. To notify a<br>
user lld might show an error in that case.<br>
<br>
BTW it looks like there is another problem with relocation addend<br>
adjustment in case of relocatable object generation. I did not<br>
investigate it thoroughly though. Suppose we have a SHF_MERGE section<br>
with two "equal" entries and a relocation which points to the second<br>
entry using section+addend. Now we merge such sections even if we<br>
generate a relocatable object. In that case we write reduced SHF_MERGE<br>
section with the only entry. But the relocation still points to the<br>
removed second entry and in fact points out of the section border.<br>
Please correct me if I miss something.<br>
<br>
I think we can fix that by the following way:<br>
1. Do not try to merge SHF_MERGE sections if Config->Relocatable is true.<br>
2. Do not group such sections together or group sections with the same<br>
SHF_STRINGS / sh_entsize parameters.<br>
3. Keep SHF_STRINGS flag and sh_entsize value when writing the<br>
sections. In that case a linker will be able to merge/reduce such<br>
sections later when it links a relocatable object to get DSO or<br>
executable file.</blockquote><div><br></div><div>I'd vote for 1. There might be a corner case that wouldn't work with that approach (maybe kernel modules?) though.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">
On Wed, Sep 28, 2016 at 11:41 PM, Rui Ueyama <<a href="mailto:ruiu@google.com">ruiu@google.com</a>> wrote:<br>
> Why this is MIPS-specific issue? Do you mean MIPS is the only architecture<br>
> that uses both REL and RELA?<br>
><br>
> On Tue, Sep 27, 2016 at 1:32 PM, Simon Atanasyan <<a href="mailto:simon@atanasyan.com">simon@atanasyan.com</a>><br>
> wrote:<br>
>><br>
>> You are right. LLD does not have this problem. Initially I bumped into<br>
>> the MIPS specific bug related to GP relative relocations calculation.<br>
>> I tried to make reproduction script as general as possible and<br>
>> mistakenly make it too general. So now with your help I realized that<br>
>> the problem solely affects MIPS.<br>
<br>
</div></div><span class="HOEnZb"><font color="#888888">--<br>
Simon Atanasyan<br>
</font></span></blockquote></div><br></div></div>