<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Mon, Nov 2, 2015 at 2:42 PM, Joerg Sonnenberger <span dir="ltr"><<a href="mailto:joerg@britannica.bec.de" target="_blank">joerg@britannica.bec.de</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">On Mon, Nov 02, 2015 at 02:26:58PM -0800, Rui Ueyama wrote:<br>
> On Mon, Nov 2, 2015 at 2:07 PM, Joerg Sonnenberger via llvm-commits <<br>
> <a href="mailto:llvm-commits@lists.llvm.org">llvm-commits@lists.llvm.org</a>> wrote:<br>
><br>
> > 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<br>
> > from<br>
> > > a DSO in reality?<br>
> ><br>
> > 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>
> ><br>
><br>
> Looks like very old BFD aligns symbols for copy relocations to 16-byte<br>
> boundaries unconditionally, but recent versions does what gold does. In<br>
> order to do the same thing, we need to add a new field to our shared symbol<br>
> class, so it needs a bit of redesigning. I don't think we need this now,<br>
> but it can be a todo.<br>
<br>
</div></div>Not exactly surprising, until AVX the largest alignment requirement of<br>
AMD64 was 16 Bytes. In theory, code could request more, but the CPU<br>
wouldn't enforce anything like that.<br></blockquote><div><br></div><div>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.</div></div></div></div>