[lld] r251526 - [ELF2] R_X86_64_COPY relocation implemented

[Joerg Sonnenberger via llvm-commits]

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.

Joerg