<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Mon, Nov 2, 2015 at 2:07 PM, Joerg Sonnenberger via llvm-commits <span dir="ltr"><<a href="mailto:llvm-commits@lists.llvm.org" target="_blank">llvm-commits@lists.llvm.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Mon, Nov 02, 2015 at 01:22:43PM -0800, Rui Ueyama wrote:<br>
> > max((S.size >= 16 ? 16 : 1), min(sect.align, 1 << fls(S.offset)))<br>
> ><br>
> > where S.size is the symbol size, S.offset is relative to the start of<br>
> > the section in the source file and sect.align the alignment attribute.<br>
><br>
><br>
> Can a result of this computation be greater than 16 for data exported from<br>
> a DSO in reality?<br>
<br>
</span>I think so. Consider a class with static AVX vectors as members. Inline<br>
functions accessing them can easily result in such copy relocations.<br></blockquote><div><br></div><div>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.</div></div></div></div>