[lld-macho] Add support for -alias

This creates a symbol alias similar to --defsym in the elf linker. This
is used by swiftpm for all executables, so it's useful to support. This
doesn't implement -

[lld-macho] Add support for -alias

This creates a symbol alias similar to --defsym in the elf linker. This
is used by swiftpm for all executables, so it's useful to support. This
doesn't implement -alias_list but that could be done pretty easily as
needed.

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

show more ...

[lld-macho] Handle user-provided dtrace symbols to avoid linking failure

This fixes https://github.com/llvm/llvm-project/issues/56238. ld64.lld currently does not generate __dof section in Mach-O, a

[lld-macho] Handle user-provided dtrace symbols to avoid linking failure

This fixes https://github.com/llvm/llvm-project/issues/56238. ld64.lld currently does not generate __dof section in Mach-O, and -no_dtrace_dof option is on by default. However when there are user-defined dtrace symbols, ld64.lld will treat them as undefined symbols, which causes the linking to fail because lld cannot find their definitions. This patch allows ld64.lld to rewrite the instructions calling dtrace symbols to instructions like nop as what ld64 does; therefore, when encountered with user-provided dtrace probes, the linking can still succeed.

I'm not sure whether support for dtrace is expected in lld, so for now I didn't add codes to make lld emit __dof section like ld64, and only made it possible to link with dtrace symbols provided. If this feature is needed, I can add that part in Dtrace.cpp & Dtrace.h.

Reviewed By: int3, #lld-macho

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

show more ...

[lld-macho] Use source information in duplicate symbol errors

Similarly to how undefined symbol diagnostics were changed in D128184,
we now show where in the source file duplicate symbols are define

[lld-macho] Use source information in duplicate symbol errors

Similarly to how undefined symbol diagnostics were changed in D128184,
we now show where in the source file duplicate symbols are defined at:

ld64.lld: error: duplicate symbol: _foo
>> defined in bar.c:42
>> /path/to/bar.o
>> defined in baz.c:1
>> /path/to/libbaz.a(baz.o)

For objects that don't contain DWARF data, the format is unchanged.

A slight difference to undefined symbol diagnostics is that we don't
print the name of the symbol on the third line, as it's already
contained on the first line.

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

show more ...

Reland "[lld-macho] Show source information for undefined references"

The error used to look like this:

ld64.lld: error: undefined symbol: _foo
>>> referenced by /path/to/bar.o:(symbol _baz+0x4

Reland "[lld-macho] Show source information for undefined references"

The error used to look like this:

ld64.lld: error: undefined symbol: _foo
>>> referenced by /path/to/bar.o:(symbol _baz+0x4)

If DWARF line information is available, we now show where in the source
the references are coming from:

ld64.lld: error: unreferenced symbol: _foo
>>> referenced by: bar.cpp:42 (/path/to/bar.cpp:42)
>>> /path/to/bar.o:(symbol _baz+0x4)

The reland is identical to the first time this landed. The fix was in D128294.
This reverts commit 0cc7ad417585b3185c32e395cc5e6cf082a347af.

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

show more ...

Revert "[lld-macho] Show source information for undefined references"

This reverts commit cd7624f15369f0d395c1edee1a0b9592083d2fe0.
See https://reviews.llvm.org/D128184#3597534

[lld-macho] Show source information for undefined references

The error used to look like this:

ld64.lld: error: undefined symbol: _foo
>>> referenced by /path/to/bar.o:(symbol _baz+0x4)

If DWA

[lld-macho] Show source information for undefined references

The error used to look like this:

ld64.lld: error: undefined symbol: _foo
>>> referenced by /path/to/bar.o:(symbol _baz+0x4)

If DWARF line information is available, we now show where in the source
the references are coming from:

ld64.lld: error: unreferenced symbol: _foo
>>> referenced by: bar.cpp:42 (/path/to/bar.cpp:42)
>>> /path/to/bar.o:(symbol _baz+0x4)

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

show more ...

Reland "[lld-macho] Group undefined symbol diagnostics by symbol".

This reverts commit 36e7c9a450db5e22af1ec21412d918ceb2313942.

This relands d61341768cf0cff7c with the fix described in
https://rev

Reland "[lld-macho] Group undefined symbol diagnostics by symbol".

This reverts commit 36e7c9a450db5e22af1ec21412d918ceb2313942.

This relands d61341768cf0cff7c with the fix described in
https://reviews.llvm.org/D127753#3587390

show more ...

Revert "[lld-macho] Group undefined symbol diagnostics by symbol"

This reverts commit d61341768cf0cff7ceeaddecc2f769b5c1b901c4.

This change broke multiple lld tests, including some sanitizer builds

Revert "[lld-macho] Group undefined symbol diagnostics by symbol"

This reverts commit d61341768cf0cff7ceeaddecc2f769b5c1b901c4.

This change broke multiple lld tests, including some sanitizer builds: https://lab.llvm.org/buildbot/#/builders/5/builds/24787/steps/19/logs/stdio

show more ...

[lld-macho] Group undefined symbol diagnostics by symbol

ld64.lld used to print the "undefined symbol" line for each reference to
an undefined symbol previously:

ld64.lld: error: undefined symbol

[lld-macho] Group undefined symbol diagnostics by symbol

ld64.lld used to print the "undefined symbol" line for each reference to
an undefined symbol previously:

ld64.lld: error: undefined symbol: _foo
>>> referenced by /path/to/bar.o:(symbol _baz+0x0)

ld64.lld: error: undefined symbol: _foo
>>> referenced by /path/to/bar.o:(symbol _quux+0x1)

Now they are deduplicated:

ld64.lld: error: undefined symbol: _foo
>>> referenced by /path/to/bar.o:(symbol _baz+0x0)
>>> referenced by /path/to/bar.o:(symbol _quux+0x1)

As with the other lld ports, only the first 3 references are printed.

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

show more ...

[lld-macho] Print the name of functions containing undefined references

The error used to look like this:

ld64.lld: error: undefined symbol: _foo
>>> referenced by /path/to/bar.o

Now it displa

[lld-macho] Print the name of functions containing undefined references

The error used to look like this:

ld64.lld: error: undefined symbol: _foo
>>> referenced by /path/to/bar.o

Now it displays the name of the function that contains the undefined
reference as well:

ld64.lld: error: undefined symbol: _foo
>>> referenced by /path/to/bar.o:(symbol _baz+0x4)

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

show more ...

[lld-macho] Demangle symbol names in duplicate-symbol error when -demangle is specified

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

[lld-macho][nfc] Use includeInSymtab for all symtab-skipping logic

{D123302} got me looking deeper at `includeInSymtab`. I thought it was a
little odd that there were excluded (live) symbols for whi

[lld-macho][nfc] Use includeInSymtab for all symtab-skipping logic

{D123302} got me looking deeper at `includeInSymtab`. I thought it was a
little odd that there were excluded (live) symbols for which
`includeInSymtab` was false; we shouldn't have so many different ways to
exclude a symbol. As such, this diff makes the `L`-prefixed-symbol
exclusion code use `includeInSymtab` too. (Note that as part of our
support for `__eh_frame`, we will also be excluding all `__eh_frame`
symbols from the symtab in a future diff.)

Another thing I noticed is that the `emitStabs` code never has to deal
with excluded symbols because `SymtabSection::finalize()` already
filters them out. As such, I've updated the comments and asserts from
{D123302} to reflect this.

Reviewed By: #lld-macho, thakis

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

show more ...

[lld/mac] Add some comments and asserts

I was wondering if SymtabSection::emitStabs() should check
defined->includeInSymtab. Add asserts and comments explaining why that's not
necessary.

No behavio

[lld/mac] Add some comments and asserts

I was wondering if SymtabSection::emitStabs() should check
defined->includeInSymtab. Add asserts and comments explaining why that's not
necessary.

No behavior change.

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

show more ...

[lld-macho] -flat_namespace for dylibs should make all externs interposable

All references to interposable symbols can be redirected at runtime to
point to a different symbol definition (with the sa

[lld-macho] -flat_namespace for dylibs should make all externs interposable

All references to interposable symbols can be redirected at runtime to
point to a different symbol definition (with the same name). For
example, if both dylib A and B define symbol _foo, and we load A before
B at runtime, then all references to _foo within dylib B will point to
the definition in dylib A.

ld64 makes all extern symbols interposable when linking with
`-flat_namespace`.

TODO 1: Support `-interposable` and `-interposable_list`, which should
just be a matter of parsing those CLI flags and setting the
`Defined::interposable` bit.

TODO 2: Set Reloc::FinalDefinitionInLinkageUnit correctly with this info
(we are currently not setting it at all, so we're erring on the
conservative side, but we should help the LTO backend generate more
optimal code.)

Reviewed By: modimo, MaskRay

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

show more ...

[lld-macho][nfc] Eliminate InputSection::Shared

Earlier in LLD's evolution, I tried to create the illusion that
subsections were indistinguishable from "top-level" sections. Thus, even
though the su

[lld-macho][nfc] Eliminate InputSection::Shared

Earlier in LLD's evolution, I tried to create the illusion that
subsections were indistinguishable from "top-level" sections. Thus, even
though the subsections shared many common field values, I hid those
common values away in a private Shared struct (see D105305). More
recently, however, @gkm added a public `Section` struct in D113241 that
served as an explicit way to store values that are common to an entire
set of subsections (aka InputSections). Now that we have another "common
value" struct, `Shared` has been rendered redundant. All its fields can
be moved into `Section` instead, and the pointer to `Shared` can be replaced
with a pointer to `Section`.

This `Section` pointer also has the advantage of letting us inspect other
subsections easily, simplifying the implementation of {D118798}.

P.S. I do think that having both `Section` and `InputSection` makes for
a slightly confusing naming scheme. I considered renaming `InputSection`
to `Subsection`, but that would break the symmetry with `OutputSection`.
It would also make us deviate from LLD-ELF's naming scheme.

This change is perf-neutral on my 3.2 GHz 16-Core Intel Xeon W machine:

base diff difference (95% CI)
sys_time 1.258 ± 0.031 1.248 ± 0.023 [ -1.6% .. +0.1%]
user_time 3.659 ± 0.047 3.658 ± 0.041 [ -0.5% .. +0.4%]
wall_time 4.640 ± 0.085 4.625 ± 0.063 [ -1.0% .. +0.3%]
samples 49 61

There's also no stat sig change in RSS (as measured by `time -l`):

base diff difference (95% CI)
time 998038627.097 ± 13567305.958 1003327715.556 ± 15210451.236 [ -0.2% .. +1.2%]
samples 31 36

Reviewed By: #lld-macho, oontvoo

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

show more ...

[lld-macho] Add --start-lib --end-lib

In ld.lld, when an ObjFile/BitcodeFile is read in --start-lib state, the file is
given archive semantics. --end-lib closes the previous --start-lib. A build
sys

[lld-macho] Add --start-lib --end-lib

In ld.lld, when an ObjFile/BitcodeFile is read in --start-lib state, the file is
given archive semantics. --end-lib closes the previous --start-lib. A build
system can use this feature as an alternative to archives. This patch ports
the feature to lld-macho.

--start-lib and --end-lib are positional, unlike usual ld64 options.
I think the slight drawback does not matter as (a) reusing option names
make build systems convenient (b) `--start-lib a.o b.o --end-lib` conveys more
information than an alternative design: `-objlib a.o -objlib b.o` because
--start-lib makes it clear which objects are in the same conceptual archive.
This provides flexibility (c) `-objlib`/`-filelist` interaction may be weird.

Close https://github.com/llvm/llvm-project/issues/52931

Reviewed By: #lld-macho, Jez Ng, oontvoo

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

show more ...

[lld-macho] Rename LazySymbol to LazyArchive. NFC

D116913 will add LazyObject. Rename LazySymbol to LazyArchive to avoid confusion
and mirror ELF.

Reviewed By: #lld-macho, Jez Ng

Differential Revi

[lld-macho] Rename LazySymbol to LazyArchive. NFC

D116913 will add LazyObject. Rename LazySymbol to LazyArchive to avoid confusion
and mirror ELF.

Reviewed By: #lld-macho, Jez Ng

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

show more ...

[lld-macho] Change some global pointers to unique_ptr

Similar to D116143. My x86-64 `lld` is ~8KiB smaller.

Reviewed By: keith

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

[lld-macho] Unreferenced weak dylib symbols shouldn't fetch archive symbols

We were fetching archive symbols too eagerly, bloating binary size as well as
just screwing up binaries that expected to l

[lld-macho] Unreferenced weak dylib symbols shouldn't fetch archive symbols

We were fetching archive symbols too eagerly, bloating binary size as well as
just screwing up binaries that expected to look up certain symbols only at
runtime.

Reviewed By: #lld-macho, oontvoo

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

show more ...

[lld-macho] Allow exporting weak_def_can_be_hidden(AKA "autohide") symbols

autohide symbols behaves similarly to private_extern symbols.
However, LD64 allows exporting autohide symbols. LLD currentl

[lld-macho] Allow exporting weak_def_can_be_hidden(AKA "autohide") symbols

autohide symbols behaves similarly to private_extern symbols.
However, LD64 allows exporting autohide symbols. LLD currently does not.
This patch allows LLD to export them.

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

show more ...

Reland "[lld-macho] Fix assertion failure in registerCompactUnwind""

PR/52372

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

New changes:
- use llvm-otool instead of `otool` which doesn

Reland "[lld-macho] Fix assertion failure in registerCompactUnwind""

PR/52372

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

New changes:
- use llvm-otool instead of `otool` which doesn't in exist on non-OSX platforms
- add llvm-otool to the set of tools used by test so that the bot will use the <build_dir>/bin/llvm-otool instead of the unqualified `llvm-otool` (which may not exist)
- update tests since the latest (TOT) llvm-otool prints a space between two bytes and the old one doesn't.

show more ...

Revert "[lld-macho] Fix assertion failure in registerCompactUnwind"

broke windows build - reverting to investigate
This reverts commit b2d92584742e333799ed6a3687c801dde9bb6174.

[lld-macho] Fix assertion failure in registerCompactUnwind

PR/52372

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

[lld-macho] Associate compact unwind entries with function symbols

Compact unwind entries (CUEs) contain pointers to their respective
function symbols. However, during the link process, it's far mor

[lld-macho] Associate compact unwind entries with function symbols

Compact unwind entries (CUEs) contain pointers to their respective
function symbols. However, during the link process, it's far more useful
to have pointers from the function symbol to the CUE than vice versa.
This diff adds that pointer in the form of `Defined::compactUnwind`.

In particular, when doing dead-stripping, we want to mark CUEs live when
their function symbol is live; and when doing ICF, we want to dedup
sections iff the symbols in that section have identical CUEs. In both
cases, we want to be able to locate the symbols within a given section,
as well as locate the CUEs belonging to those symbols. So this diff also
adds `InputSection::symbols`.

The ultimate goal of this refactor is to have ICF support dedup'ing
functions with unwind info, but that will be handled in subsequent
diffs. This diff focuses on simplifying `-dead_strip` --
`findFunctionsWithUnwindInfo` is no longer necessary, and
`Defined::isLive()` is now a lot simpler. Moreover, UnwindInfoSection no
longer has to check for dead CUEs -- we simply avoid adding them in the
first place.

Additionally, we now support stripping of dead LSDAs, which follows
quite naturally since `markLive()` can now reach them via the CUEs.

Reviewed By: #lld-macho, gkm

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

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 ...