[lld] r296448 - Add a comment.
Sean Silva via llvm-commits
llvm-commits at lists.llvm.org
Tue Feb 28 18:08:41 PST 2017
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.
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.
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.
-- Sean Silva
>
> Cheers,
> Rafael
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20170228/c4758f0f/attachment.html>
More information about the llvm-commits
mailing list