[lld] r296448 - Add a comment.

[Rafael Avila de Espindola via llvm-commits]

Sean Silva <chisophugis at gmail.com> writes:

> On Tue, Feb 28, 2017 at 11:20 AM, Rafael Avila de Espindola <
> rafael.espindola at gmail.com> wrote:
>
>> > +    // Note that for an ordinary symbol we do not perform this
>> > +    // adjustment and thus effectively assume that the addend cannot
>> > +    // cross the boundaries of mergeable objects.
>>
>> That is not the assumption. The issue is that ".rodata + 42" and ".Lbar
>> + 42" have different meanings. The first one means the data that starts
>> 42 bytes after the start of .rodata. The second one means 42 bytes after
>> the data that starts at .Lbar.
>>
>> An example that shows the difference
>>
>>
>>         .section        .rodata.str1.1,"aMS", at progbits,1
>> .Lbar:
>>         .asciz  "abc"
>>         .asciz  "def"
>>
>>         .data
>>         .quad .Lbar + 4
>>         .quad .rodata.str1.1 + 4
>>
>> The first relocation points to 4 bytes after "abc". The second
>> relocation points to "def".
>>
>
> That's what I was trying to get at with :
> ```
> +    // We must incorporate the addend into the section offset (and
> +    // zero out the addend for later processing) so that we find the
> +    // right object in the section.
> ```
>
> 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.
>
> Am I understanding correctly? I'll update the comment if so.

The only issue I noticed with the comment was the part:

>> > +    // adjustment and thus effectively assume that the addend cannot
>> > +    // cross the boundaries of mergeable objects.

With a non section symbol the addend can cross the boundary. The meaning
is that at runtime the value will be past the end of the object.

> 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.

I think we don't support relocatons pointing to arbitrary locations in
.eh_frame.

Cheers,
Rafael