llvm-project/lld/MachO/ld64-vs-lld.rst

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

38 lines
1.4 KiB
ReStructuredText
Raw Normal View History

==================
LD64 vs LLD-MACHO
==================
This doc lists all significant deliberate differences in behavior between LD64 and LLD-MachO.
String Literal Deduplication
****************************
LD64 always deduplicates string literals. LLD only does it when the ``--icf=``
or the ``--deduplicate-literals`` flag is passed. Omitting deduplication by
default ensures that our link is as fast as possible. However, it may also break
some programs which have (incorrectly) relied on string deduplication always
2022-01-20 15:59:12 +08:00
occurring. In particular, programs which compare string literals via pointer
equality must be fixed to use value equality instead.
[lld-macho] Align cstrings less conservatively Previously, we aligned every cstring to 16 bytes as a temporary hack to deal with https://github.com/llvm/llvm-project/issues/50135. However, it was highly wasteful in terms of binary size. To recap, in contrast to ELF, which puts strings that need different alignments into different sections, `clang`'s Mach-O backend puts them all in one section. Strings that need to be aligned have the .p2align directive emitted before them, which simply translates into zero padding in the object file. In other words, we have to infer the alignment of the cstrings from their addresses. We differ slightly from ld64 in how we've chosen to align these cstrings. Both LLD and ld64 preserve the number of trailing zeros in each cstring's address in the input object files. When deduplicating identical cstrings, both linkers pick the cstring whose address has more trailing zeros, and preserve the alignment of that address in the final binary. However, ld64 goes a step further and also preserves the offset of the cstring from the last section-aligned address. I.e. if a cstring is at offset 18 in the input, with a section alignment of 16, then both LLD and ld64 will ensure the final address is 2-byte aligned (since `18 == 16 + 2`). But ld64 will also ensure that the final address is of the form 16 * k + 2 for some k (which implies 2-byte alignment). Note that ld64's heuristic means that a dedup'ed cstring's final address is dependent on the order of the input object files. E.g. if in addition to the cstring at offset 18 above, we have a duplicate one in another file with a `.cstring` section alignment of 2 and an offset of zero, then ld64 will pick the cstring from the object file earlier on the command line (since both have the same number of trailing zeros in their address). So the final cstring may either be at some address `16 * k + 2` or at some address `2 * k`. I've opted not to follow this behavior primarily for implementation simplicity, and secondarily to save a few more bytes. It's not clear to me that preserving the section alignment + offset is ever necessary, and there are many cases that are clearly redundant. In particular, if an x86_64 object file contains some strings that are accessed via SIMD instructions, then the .cstring section in the object file will be 16-byte-aligned (since SIMD requires its operand addresses to be 16-byte aligned). However, there will typically also be other cstrings in the same file that aren't used via SIMD and don't need this alignment. They will be emitted at some arbitrary address `A`, but ld64 will treat them as being 16-byte aligned with an offset of `16 % A`. I have verified that the two repros in https://github.com/llvm/llvm-project/issues/50135 work well with the new alignment behavior. Fixes https://github.com/llvm/llvm-project/issues/54036. Reviewed By: #lld-macho, oontvoo Differential Revision: https://reviews.llvm.org/D121342
2022-03-11 04:04:31 +08:00
String Alignment
****************
LLD is slightly less conservative about aligning cstrings, allowing it to pack
them more compactly. This should not result in any meaningful semantic
difference.
``-no_deduplicate`` Flag
************************
- LD64:
* This turns off ICF (deduplication pass) in the linker.
- LLD
* This turns off ICF and string merging in the linker.
ObjC Symbols Treatment
**********************
There are differences in how LLD and LD64 handle ObjC symbols loaded from archives.
- LD64:
* Duplicate ObjC symbols from the same archives will not raise an error. LD64 will pick the first one.
* Duplicate ObjC symbols from different archives will raise a "duplicate symbol" error.
- LLD:
* Duplicate symbols, regardless of which archives they are from, will raise errors.