[MachO] Properly reset global state

We need to reset global state between runs, similar to the other ports.
There's some file-static state which needs to be reset as well and we
need to add some new

[MachO] Properly reset global state

We need to reset global state between runs, similar to the other ports.
There's some file-static state which needs to be reset as well and we
need to add some new helpers for that.

With this change, most LLD Mach-O tests pass with `LLD_IN_TEST=2` (which
runs the linker twice on each test). Some tests will be fixed by the
remainder of this stack, and the rest are fundamentally incompatible
with that mode (e.g. they intentionally throw fatal errors).

Fixes PR52070.

Reviewed By: #lld-macho, int3

Differential Revision: https://reviews.llvm.org/D112878

show more ...

[lld/mac] Add support for segment$start$ and segment$end$ symbols

These symbols are somewhat interesting in that they create non-existing
segments, which as far as I know is the only way to create s

[lld/mac] Add support for segment$start$ and segment$end$ symbols

These symbols are somewhat interesting in that they create non-existing
segments, which as far as I know is the only way to create segments
that don't contain any sections.

Final part of part of PR50760. Like D106629, but for segments instead
of sections. I'm not aware of anything that needs this in practice.

Differential Revision: https://reviews.llvm.org/D106767

show more ...

[lld/mac] Move output segment rename logic into OutputSegment

Fixes the output segment name if both -rename_section and
-rename_segment are used and the post-section-rename segment
name is the same

[lld/mac] Move output segment rename logic into OutputSegment

Fixes the output segment name if both -rename_section and
-rename_segment are used and the post-section-rename segment
name is the same as the pre-segment-rename segment name to
match ld64's behavior.

The motivation is that segment$start$ can create section-less segments,
and this makes a corner case in the interaction between segment$start and
-rename_segment in the upcoming segment$start patch.

Differential Revision: https://reviews.llvm.org/D106766

show more ...

[lld/mac] Fix start-stop.s test with expensive checks enabled

See e.g. https://lab.llvm.org/buildbot/#/builders/16/builds/14317
Not 100% sure why this fails yet, but this fixes it. Let's get
the bot

[lld/mac] Fix start-stop.s test with expensive checks enabled

See e.g. https://lab.llvm.org/buildbot/#/builders/16/builds/14317
Not 100% sure why this fails yet, but this fixes it. Let's get
the bots green again first :)

Differential Revision: https://reviews.llvm.org/D106711

show more ...

[lld/mac] Fix nondeterminism in output section ordering

The two different thread_local_regular sections (__thread_data and
more_thread_data) had nondeterminstic ordering for two reasons:

1. https:/

[lld/mac] Fix nondeterminism in output section ordering

The two different thread_local_regular sections (__thread_data and
more_thread_data) had nondeterminstic ordering for two reasons:

1. https://reviews.llvm.org/D102972 changed concatOutputSections
from MapVector to DenseMap, so when we iterate it to make
output segments, we would add the two sections to the __DATA
output segment in nondeterministic order.

2. The same change also moved the two stable_sort()s for segments
and sections to sort(). Since sections with assigned priority
(such as TLV data) have the same priority for all sections,
this is incorrect -- we must use stable_sort() so that the
initial (input-order-based) order remains.

As a side effect, we now (deterministically) put the __common
section in front of __bss (while previously we happened to
put it after it). (__common and __bss are both zerofill so
both have order INT_MAX, but common symbols are added to
inputSections before normal sections are collected.)

Makes lld/test/MachO/tlv.s and lld/test/MachO/tlv-dylib.s pass with
LLVM_ENABLE_EXPENSIVE_CHECKS=ON.

Differential Revision: https://reviews.llvm.org/D105054

show more ...

[lld/mac] Test zerofill sections after __thread_bss

Real zerofill sections go after __thread_bss, since zerofill sections
must all be at the end of their segment and __thread_bss must be right
after

[lld/mac] Test zerofill sections after __thread_bss

Real zerofill sections go after __thread_bss, since zerofill sections
must all be at the end of their segment and __thread_bss must be right
after __thread_data.

Works fine already, but wasn't tested as far as I can tell.

Also tweak comment about zerofill sections a bit.

No behavior change.

Differential Revision: https://reviews.llvm.org/D104609

show more ...

[lld/mac] Make sure __thread_ptrs is in front of __thread_bss

The exact location doesn't matter, but it should be in front
of __thread_bss. We put it right in front of __thread_data
which is where l

[lld/mac] Make sure __thread_ptrs is in front of __thread_bss

The exact location doesn't matter, but it should be in front
of __thread_bss. We put it right in front of __thread_data
which is where ld64 seems to put it as well.

Fixes PR50769.

(As mentioned on the bug, there is probably a more structural
fix too, see comment 5. If we don't address this, it's likely
we'll run into this again with other synthetic sections. But
for now, let's fix the immediate breakage.)

Differential Revision: https://reviews.llvm.org/D104596

show more ...

[lld-macho] Put DATA_IN_CODE immediately after FUNCTION_STARTS

codesign checks for this.

Reviewed By: #lld-macho, thakis

Differential Revision: https://reviews.llvm.org/D104354

[lld-macho][nfc] Remove unnecessary parameterization of section sort

As @alexshap pointed out [here](https://reviews.llvm.org/D102972#inline-975208),
it's a bit confusing to have the option to sort

[lld-macho][nfc] Remove unnecessary parameterization of section sort

As @alexshap pointed out [here](https://reviews.llvm.org/D102972#inline-975208),
it's a bit confusing to have the option to sort OutputSections with any
comparator when in practice we only use one.

Reviewed By: #lld-macho, alexshap, thakis

Differential Revision: https://reviews.llvm.org/D102974

show more ...

[lld-macho][nfc] Sort OutputSections based on explicit order of command-line inputs

This diff paves the way for {D102964} which adds a new kind of
InputSection.

We previously maintained section ord

[lld-macho][nfc] Sort OutputSections based on explicit order of command-line inputs

This diff paves the way for {D102964} which adds a new kind of
InputSection.

We previously maintained section ordering implicitly: we created
InputSections as we parsed each file in command-line order, and passed
on this ordering when we created OutputSections and OutputSegments by
iterating over these InputSections. The implicitness of the ordering
made it difficult to refactor the code to e.g. handle a new type of
InputSection. As such, I've codified the ordering explicitly via
`inputOrder` fields. This also allows us to use `sort` instead of
`stable_sort`.

Benchmarking chromium_framework on my 3.2 GHz 16-Core Intel Xeon W:

N Min Max Median Avg Stddev
x 20 4.23 4.35 4.27 4.274 0.030157481
+ 20 4.24 4.38 4.27 4.2815 0.033759989
No difference proven at 95.0% confidence

Reviewed By: #lld-macho, alexshap

Differential Revision: https://reviews.llvm.org/D102972

show more ...

[lld-macho][nfc] Rename MergedOutputSection to ConcatOutputSection

The ELF format has the concept of merge sections (marked by SHF_MERGE),
which contain data that can be safely deduplicated. The Mac

[lld-macho][nfc] Rename MergedOutputSection to ConcatOutputSection

The ELF format has the concept of merge sections (marked by SHF_MERGE),
which contain data that can be safely deduplicated. The Mach-O
equivalents are called literal sections (marked by S_CSTRING_LITERALS or
S_{4,8,16}BYTE_LITERALS). While the Mach-O format doesn't use the word
'merge', to avoid confusion, I've renamed our MergedOutputSection to
ConcatOutputSection. I believe it's a more descriptive name too.

This renaming sets the stage for {D102964}.

Reviewed By: #lld-macho, alexshap

Differential Revision: https://reviews.llvm.org/D102971

show more ...

[lld/mac] Implement -sectalign

clang sometimes passes this flag along (see D68351), so we should implement it.

Differential Revision: https://reviews.llvm.org/D102247

[lld-macho][nfc] Add accessors for commonly-used PlatformInfo fields

As discussed here: https://reviews.llvm.org/D100523#inline-951543

Reviewed By: #lld-macho, thakis, alexshap

Differential Revisi

[lld-macho][nfc] Add accessors for commonly-used PlatformInfo fields

As discussed here: https://reviews.llvm.org/D100523#inline-951543

Reviewed By: #lld-macho, thakis, alexshap

Differential Revision: https://reviews.llvm.org/D100978

show more ...

[lld][MachO] Add support for LC_VERSION_MIN_* load commands

This diff adds initial support for the legacy LC_VERSION_MIN_* load commands.

Test plan: make check-lld-macho

Differential revision: htt

[lld][MachO] Add support for LC_VERSION_MIN_* load commands

This diff adds initial support for the legacy LC_VERSION_MIN_* load commands.

Test plan: make check-lld-macho

Differential revision: https://reviews.llvm.org/D100523

show more ...

[lld-macho] Implement -segprot

Addresses llvm.org/PR49405.

Reviewed By: #lld-macho, oontvoo

Differential Revision: https://reviews.llvm.org/D99389

[lld-macho][NFC] Drop unnecessary braces around simple if/for bodies

Minor cleanup

Differential Revision: https://reviews.llvm.org/D98758

[lld-macho] Filter TAPI re-exports by target

Previously, we were loading re-exports without checking whether
they were compatible with our target. Prior to {D97209}, it meant that
we were defining d

[lld-macho] Filter TAPI re-exports by target

Previously, we were loading re-exports without checking whether
they were compatible with our target. Prior to {D97209}, it meant that
we were defining dylib symbols that were invalid -- usually a silent
failure unless our binary actually used them. D97209 exposed this as an
explicit error.

Along the way, I've extended our TAPI compatibility check to cover the
platform as well, instead of just checking the arch. To this end, I've
replaced MachO::Architecture with MachO::Target in our Config struct.

Reviewed By: #lld-macho, oontvoo

Differential Revision: https://reviews.llvm.org/D97867

show more ...

[lld-macho] Remove unnecessary llvm:: namespace prefixes

[lld-macho][easy] Fix segment max protection

We should have maxprot == initprot for all non-i386 architectures, which
is what ld64 does.

Reviewed By: #lld-macho, compnerd

Differential Revision: ht

[lld-macho][easy] Fix segment max protection

We should have maxprot == initprot for all non-i386 architectures, which
is what ld64 does.

Reviewed By: #lld-macho, compnerd

Differential Revision: https://reviews.llvm.org/D89420

show more ...

[lld-macho][NFC] Make `!= nullptr` implicit

[lld-macho] Refactor segment/section creation, sorting, and merging

Summary:
There were a few issues with the previous setup:

1. The section sorting comparator used a declarative map of section nam

[lld-macho] Refactor segment/section creation, sorting, and merging

Summary:
There were a few issues with the previous setup:

1. The section sorting comparator used a declarative map of section names to
determine the correct order, but it turns out we need to match on more than
just names -- in particular, an upcoming diff will sort based on whether the
S_ZERO_FILL flag is set. This diff changes the sorter to a more imperative but
flexible form.

2. We were sorting OutputSections stored in a MapVector, which left the
MapVector in an inconsistent state -- the wrong keys map to the wrong values!
In practice, we weren't doing key lookups (only container iteration) after the
sort, so this was fine, but it was still a dubious state of affairs. This diff
copies the OutputSections to a vector before sorting them.

3. We were adding unneeded OutputSections to OutputSegments and then filtering
them out later, which meant that we had to remember whether an OutputSegment
was in a pre- or post-filtered state. This diff only adds the sections to the
segments if they are needed.

In addition to those major changes, two minor ones worth noting:

1. I renamed all OutputSection variable names to `osec`, to parallel `isec`.
Previously we were using some inconsistent combination of `osec`, `os`, and
`section`.

2. I added a check (and a test) for InputSections with names that clashed with
those of our synthetic OutputSections.

Reviewers: #lld-macho

Subscribers: llvm-commits

Tags: #llvm

Differential Revision: https://reviews.llvm.org/D81887

show more ...

[lld-macho] Support -order_file

The order file indicates how input sections should be sorted within each
output section, based on the symbols contained within those sections.

This diff sets the sta

[lld-macho] Support -order_file

The order file indicates how input sections should be sorted within each
output section, based on the symbols contained within those sections.

This diff sets the stage for implementing and testing
`.subsections_via_symbols`, where we will break up InputSections by each
symbol and sort them more granularly.

Reviewed By: smeenai

Differential Revision: https://reviews.llvm.org/D79668

show more ...

[lld-macho] Follow-up to D77893

Summary:
1. Don't have isHidden() depend on isNeeded(). Whether a section is
hidden is orthogonal from whether it is needed: hidden sections will
never have a hea

[lld-macho] Follow-up to D77893

Summary:
1. Don't have isHidden() depend on isNeeded(). Whether a section is
hidden is orthogonal from whether it is needed: hidden sections will
never have a header regardless of whether they have a body. (I know we
override this method with return false for synthetic sections, but
regardless I think it's confusing to write it this way for non-synthetic
sections.)

2. Don't call writeTo() on unneeded sections. D78270 assumes that this
is true when implementing the stub helper section.

3. Filter out the unneeded sections early on to avoid having to deal
with them in multiple places.

4. Remove assumption in test that the referenced file has no other symbols.
(We should create separate input files for future tests to avoid such
issues.)

Reviewers: ruiu, pcc, MaskRay, smeenai, alexshap, gkm, Ktwu, christylee

Subscribers: llvm-commits

Tags: #llvm

Differential Revision: https://reviews.llvm.org/D79460

show more ...

[lld] Merge Mach-O input sections

Summary: Similar to other formats, input sections in the MachO
implementation are now grouped under output sections. This is primarily
a refactor, although there's

[lld] Merge Mach-O input sections

Summary: Similar to other formats, input sections in the MachO
implementation are now grouped under output sections. This is primarily
a refactor, although there's some new logic (like resolving the output
section's flags based on its inputs).

Differential Revision: https://reviews.llvm.org/D77893

show more ...

[lld-macho] Extend SyntheticSections to cover all segment load commands

Previously, the special segments `__PAGEZERO` and `__LINKEDIT` were
implemented as special LoadCommands. This diff implements

[lld-macho] Extend SyntheticSections to cover all segment load commands

Previously, the special segments `__PAGEZERO` and `__LINKEDIT` were
implemented as special LoadCommands. This diff implements them using
special sections instead which have an `isHidden()` attribute. We do not
emit section headers for hidden sections, but we use their addresses and
file offsets to determine that of their containing segments. In addition
to allowing us to share more segment-related code, this refactor is also
important for the next step of emitting dylibs:

1) dylibs don't have segments like __PAGEZERO, so we need an easy way of
omitting them w/o messing up segment indices
2) Unlike the kernel, which is happy to run an executable with
out-of-order segments, dyld requires dylibs to have their segment
load commands arranged in increasing address order. The refactor
makes it easier to implement sorting of sections and segments.

Differential Revision: https://reviews.llvm.org/D76839

show more ...