[lld] r296448 - Add a comment.

[Sean Silva via llvm-commits]

On Tue, Feb 28, 2017 at 6:49 PM, Rafael Avila de Espindola <
rafael.espindola at gmail.com> wrote:

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


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

i've revised the comment in r296580.

-- Sean Silva


>
> > 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20170228/9d40bbb2/attachment.html>