<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Feb 28, 2017 at 11:20 AM, Rafael Avila de Espindola <span dir="ltr"><<a href="mailto:rafael.espindola@gmail.com" target="_blank">rafael.espindola@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="gmail-">> +    // Note that for an ordinary symbol we do not perform this<br>
> +    // adjustment and thus effectively assume that the addend cannot<br>
> +    // cross the boundaries of mergeable objects.<br>
<br>
</span>That is not the assumption. The issue is that ".rodata + 42" and ".Lbar<br>
+ 42" have different meanings. The first one means the data that starts<br>
42 bytes after the start of .rodata. The second one means 42 bytes after<br>
the data that starts at .Lbar.<br>
<br>
An example that shows the difference<br>
<br>
<br>
        .section        .rodata.str1.1,"aMS",@<wbr>progbits,1<br>
.Lbar:<br>
        .asciz  "abc"<br>
        .asciz  "def"<br>
<br>
        .data<br>
        .quad .Lbar + 4<br>
        .quad .rodata.str1.1 + 4<br>
<br>
The first relocation points to 4 bytes after "abc". The second<br>
relocation points to "def".<br></blockquote><div><br></div><div>That's what I was trying to get at with :</div><div>```</div><div><div>+    // We must incorporate the addend into the section offset (and</div><div>+    // zero out the addend for later processing) so that we find the</div><div>+    // right object in the section.</div></div><div>```</div><div><br></div><div>If I understand what you are saying, then the point is that for STT_SECTION, the addend is not really an addend in the traditional sense (offset from a symbol in the output). It really just means something else, in particular, it is just an offset to be used to find a particular object in the input.</div><div><br></div><div>Am I understanding correctly? I'll update the comment if so.<br></div><div><br></div><div>Still, I'm somewhat wary of describing it with such generality though. Do we also apply this special logic to STT_SECTION in the case of .eh_frame sections? Looking at MarkLive.cpp, I see that the offset only plays a role for mergeable sections, so I suspect we don't.</div><div><br></div><div>Having a notion of offsets w.r.t. the input that need to be resolved to a subobject is a pretty major new concept to add to the linker. I guess it really only affects mergeable sections and .eh_frame sections, which are the only cases I can think of where the content of the input section doesn't get copied as a unit into the output. Still, the fact that (I think) we don't actually support this for .eh_frame suggests that we really want to describe this as a special hack specifically for SHF_MERGE.</div><div><br></div><div>-- Sean Silva</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
Cheers,<br>
Rafael<br>
</blockquote></div><br></div></div>