<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Mon, Nov 2, 2015 at 12:01 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 10:57:23AM -0800, Rui Ueyama via llvm-commits 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 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>
</span>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></blockquote><div><br></div><div>I don't get the meaning of the latter half. Can you elaborate? </div></div></div></div>