[lld] r251526 - [ELF2] R_X86_64_COPY relocation implemented

[Rui Ueyama via llvm-commits]

On Mon, Nov 2, 2015 at 1:06 PM, Joerg Sonnenberger via llvm-commits <
llvm-commits at lists.llvm.org> wrote:

> On Mon, Nov 02, 2015 at 12:22:42PM -0800, Rui Ueyama wrote:
> > On Mon, Nov 2, 2015 at 12:01 PM, Joerg Sonnenberger via llvm-commits <
> > llvm-commits at lists.llvm.org> wrote:
> >
> > > On Mon, Nov 02, 2015 at 10:57:23AM -0800, Rui Ueyama via llvm-commits
> > > wrote:
> > > > If we push hard, a symbol alignment can be computed from the section
> > > > alignment *and* the offset of the symbol in the section. For
> example, if
> > > > symbol S is at offset 24 in a section whose alignment is 16, S needs
> to
> > > be
> > > > aligned on a 8 byte boundary. That's what gold does.
> > > >
> > > > But I don't think we really need that because I think the number of
> copy
> > > > relocations is small. Saving a few bytes doesn't seem to make sense.
> > >
> > > Things break if the alignment is not handled appropiately. See the
> > > recent libc++-on-FreeBSD discussion. So I think the rule should be:
> > >
> > > max((S.size >= 16 ? 16 : 1), (1 << fls(sect.align - S.offset)))
> > >
> > > or something like that. In theory, the first half is redundant if the
> > > linker of the other library behaves correctly, but I wouldn't put
> > > unnecessary faith in it...
> > >
> >
> > I don't get the meaning of the latter half. Can you elaborate?
>
> Sorry, it was not correct either :)
>
> max((S.size >= 16 ? 16 : 1), min(sect.align, 1 << fls(S.offset)))
>
> where S.size is the symbol size, S.offset is relative to the start of
> the section in the source file and sect.align the alignment attribute.


Can a result of this computation be greater than 16 for data exported from
a DSO in reality?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20151102/032ecb5c/attachment.html>