[lld] r296448 - Add a comment.

[Sean Silva via llvm-commits]

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>