[lld] r296448 - Add a comment.
Rafael Avila de Espindola via llvm-commits
llvm-commits at lists.llvm.org
Tue Feb 28 18:49:01 PST 2017
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
More information about the llvm-commits
mailing list