<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Feb 28, 2017 at 6:49 PM, 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"><div class="gmail-HOEnZb"><div class="gmail-h5">Sean Silva <<a href="mailto:chisophugis@gmail.com">chisophugis@gmail.com</a>> writes:<br>
<br>
> On Tue, Feb 28, 2017 at 11:20 AM, Rafael Avila de Espindola <<br>
> <a href="mailto:rafael.espindola@gmail.com">rafael.espindola@gmail.com</a>> wrote:<br>
><br>
>> > +    // 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>
>> 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>
>><br>
><br>
> That's what I was trying to get at with :<br>
> ```<br>
> +    // We must incorporate the addend into the section offset (and<br>
> +    // zero out the addend for later processing) so that we find the<br>
> +    // right object in the section.<br>
> ```<br>
><br>
> If I understand what you are saying, then the point is that for<br>
> STT_SECTION, the addend is not really an addend in the traditional sense<br>
> (offset from a symbol in the output). It really just means something else,<br>
> in particular, it is just an offset to be used to find a particular object<br>
> in the input.<br>
><br>
> Am I understanding correctly? I'll update the comment if so.<br>
<br>
</div></div>The only issue I noticed with the comment was the part:<br>
<span class="gmail-"><br>
>> > +    // adjustment and thus effectively assume that the addend cannot<br>
>> > +    // cross the boundaries of mergeable objects.<br>
<br>
</span>With a non section symbol the addend can cross the boundary. The meaning<br>
is that at runtime the value will be past the end of the object.<br></blockquote><div><br></div><div><br></div><div>Yeah, I'll delete that. I was trying to capture the notion that if it crossed the boundary, it wouldn't select the next object, it would just be off the end (which can be well-defined, albeit somewhat unusual).</div><div><br></div><div>i've revised the comment in r296580.</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">
<span class="gmail-"><br>
> Still, I'm somewhat wary of describing it with such generality though. Do<br>
> we also apply this special logic to STT_SECTION in the case of .eh_frame<br>
> sections? Looking at MarkLive.cpp, I see that the offset only plays a role<br>
> for mergeable sections, so I suspect we don't.<br>
<br>
</span>I think we don't support relocatons pointing to arbitrary locations in<br>
.eh_frame.<br>
<br>
Cheers,<br>
Rafael<br>
</blockquote></div><br></div></div>