[lld] r251526 - [ELF2] R_X86_64_COPY relocation implemented

[Rui Ueyama via llvm-commits]

On Mon, Nov 2, 2015 at 2:42 PM, Joerg Sonnenberger <joerg at britannica.bec.de>
wrote:

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

Even before AVX, that could be wrong from a theoretical point of view. You
might want to enforce some large alignment for whatever reason (such as for
tagged pointer), and such code wouldn't work with the old BFD linker. I'd
like to say "don't rely too much on the alignment of copied symbols"
instead of fixing the issue because copy relocations are not a very good
invention. It wastes space. It makes not only symbol's name but also
symbol's size and alignments part of the ABI. I'm not against doing
something for this in future, but this is my feeling.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20151102/75427869/attachment-0001.html>