[lld] r251526 - [ELF2] R_X86_64_COPY relocation implemented

[Joerg Sonnenberger via llvm-commits]

On Mon, Nov 02, 2015 at 02:26:58PM -0800, Rui Ueyama wrote:
> On Mon, Nov 2, 2015 at 2:07 PM, Joerg Sonnenberger via llvm-commits <
> llvm-commits at lists.llvm.org> wrote:
> 
> > On Mon, Nov 02, 2015 at 01:22:43PM -0800, Rui Ueyama wrote:
> > > > 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?
> >
> > I think so. Consider a class with static AVX vectors as members. Inline
> > functions accessing them can easily result in such copy relocations.
> >
> 
> Looks like very old BFD aligns symbols for copy relocations to 16-byte
> boundaries unconditionally, but recent versions does what gold does. In
> order to do the same thing, we need to add a new field to our shared symbol
> class, so it needs a bit of redesigning. I don't think we need this now,
> but it can be a todo.

Not exactly surprising, until AVX the largest alignment requirement of
AMD64 was 16 Bytes. In theory, code could request more, but the CPU
wouldn't enforce anything like that.

Joerg