[lld] r251526 - [ELF2] R_X86_64_COPY relocation implemented

Joerg Sonnenberger via llvm-commits llvm-commits at lists.llvm.org
Mon Nov 2 12:01:30 PST 2015


On Mon, Nov 02, 2015 at 10:57:23AM -0800, Rui Ueyama via llvm-commits wrote:
> If we push hard, a symbol alignment can be computed from the section
> alignment *and* the offset of the symbol in the section. For example, if
> symbol S is at offset 24 in a section whose alignment is 16, S needs to be
> aligned on a 8 byte boundary. That's what gold does.
> 
> But I don't think we really need that because I think the number of copy
> relocations is small. Saving a few bytes doesn't seem to make sense.

Things break if the alignment is not handled appropiately. See the
recent libc++-on-FreeBSD discussion. So I think the rule should be:

max((S.size >= 16 ? 16 : 1), (1 << fls(sect.align - S.offset)))

or something like that. In theory, the first half is redundant if the
linker of the other library behaves correctly, but I wouldn't put
unnecessary faith in it...

Joerg


More information about the llvm-commits mailing list