[lld] r251526 - [ELF2] R_X86_64_COPY relocation implemented

[Rui Ueyama via llvm-commits]

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?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20151102/6312b334/attachment.html>