<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Mon, Nov 2, 2015 at 1:06 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"><div class="HOEnZb"><div class="h5">On Mon, Nov 02, 2015 at 12:22:42PM -0800, Rui Ueyama wrote:<br>
> On Mon, Nov 2, 2015 at 12:01 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 10:57:23AM -0800, Rui Ueyama via llvm-commits<br>
> > wrote:<br>
> > > If we push hard, a symbol alignment can be computed from the section<br>
> > > alignment *and* the offset of the symbol in the section. For example, if<br>
> > > symbol S is at offset 24 in a section whose alignment is 16, S needs to<br>
> > be<br>
> > > aligned on a 8 byte boundary. That's what gold does.<br>
> > ><br>
> > > But I don't think we really need that because I think the number of copy<br>
> > > relocations is small. Saving a few bytes doesn't seem to make sense.<br>
> ><br>
> > Things break if the alignment is not handled appropiately. See the<br>
> > recent libc++-on-FreeBSD discussion. So I think the rule should be:<br>
> ><br>
> > max((S.size >= 16 ? 16 : 1), (1 << fls(sect.align - S.offset)))<br>
> ><br>
> > or something like that. In theory, the first half is redundant if the<br>
> > linker of the other library behaves correctly, but I wouldn't put<br>
> > unnecessary faith in it...<br>
> ><br>
><br>
> I don't get the meaning of the latter half. Can you elaborate?<br>
<br>
</div></div>Sorry, it was not correct either :)<br>
<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.</blockquote><div><br></div><div>Can a result of this computation be greater than 16 for data exported from a DSO in reality?</div></div></div></div>