[lld] r251526 - [ELF2] R_X86_64_COPY relocation implemented

Rui Ueyama via llvm-commits llvm-commits at lists.llvm.org
Mon Nov 2 14:26:58 PST 2015


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


More information about the llvm-commits mailing list