Commit Graph

4 Commits

Author SHA1 Message Date
Jez Ng fd28f71872 [lld-macho] Have tests default to targeting macos 10.15
D101114 enforced proper version checks, which exposed a variety of version
mismatch issues in our tests. We previously changed the test inputs to
target 10.0, which was the simpler thing to do, but we should really
just have our lit.local.cfg default to targeting 10.15, which is what is done
here. We're not likely to ever have proper support for the older versions
anyway, as that would require more work for unclear benefit; for instance,
llvm-mc seems to generate a different compact unwind format for older macOS
versions, which would cause our compact-unwind.s test to fail.

Targeting 10.15 by default causes the following behavioral changes:
* `__mh_execute_header` is now a section symbol instead of an absolute symbol
* LC_BUILD_VERSION gets emitted instead of LC_VERSION_MIN_MACOSX. The former is
  32 bytes in size whereas the latter is 16 bytes, so a bunch of hardcoded
  address offsets in our tests had to be updated.
* >= 10.6 executables are PIE by default

Note that this diff was stacked atop of a local revert of most of the test
changes in rG8c17a875150f8e736e8f9061ddf084397f45f4c5, to make review easier.

Reviewed By: #lld-macho, oontvoo

Differential Revision: https://reviews.llvm.org/D101119
2021-04-23 09:25:08 -04:00
Jez Ng 8c17a87515 [re-land][lld-macho] Fix min version check
We had got it backwards... the minimum version of the target
should be higher than the min version of the object files, presumably
since new platforms are backwards-compatible with older formats.

Fixes PR50078.

The original commit (aa05439c9c) broke many tests that had inputs too
new for our target platform (10.0). This commit changes the inputs to
target 10.0, which was the simpler thing to do, but we should really
just have our lit.local.cfg default to targeting 10.15... we're not
likely to ever have proper support for the older versions anyway. I will
follow up with a change to that effect.

Differential Revision: https://reviews.llvm.org/D101114
2021-04-22 19:35:32 -04:00
Jez Ng eb5b7d4497 [lld-macho] LTO: Unset VisibleToRegularObj where possible
This allows LLVM's LTO to internalize symbols that are not referenced
directly by regular objects. Naturally, this means we need to track
which symbols are referenced by regular objects. The approach taken here
is similar to LLD-COFF's: like the COFF port, we extend
`SymbolTable::insert()` to set the isVisibleToRegularObj bit. (LLD-ELF
relies on the Symbol constructor and `Symbol::mergeProperties()`, but
the Mach-O port does not have a `mergeProperties()` equivalent.)

From what I can tell, ld64 (which uses libLTO) doesn't do this
optimization at all. I'm not even sure libLTO provides a way to do this.
Not having ld64's behavior as a reference implementation is unfortunate;
instead, I am relying on LLD-ELF/COFF's behavior as references while
erring on the conservative side. In particular, LLD-MachO will only do
this optimization for executables right now.

We also don't attempt it when `-flat_namespace` is used -- otherwise
we'd need scan the symbol table to find matches for every un-namespaced
symbol reference, which is expensive.

internalize.ll is based off the LLD-ELF tests `internalize-basic.ll` and
`internalize-undef.ll`. Looks like @davide added some of LLD-ELF's internalize
tests, so adding him as a reviewer...

Reviewed By: #lld-macho, gkm

Differential Revision: https://reviews.llvm.org/D99105
2021-04-15 21:16:33 -04:00
Jez Ng 21f831134c [lld-macho] Add very basic support for LTO
Just enough to consume some bitcode files and link them. There's more
to be done around the symbol resolution API and the LTO config, but I don't yet
understand what all the various LTO settings do...

Reviewed By: #lld-macho, compnerd, smeenai, MaskRay

Differential Revision: https://reviews.llvm.org/D90663
2020-11-10 12:19:28 -08:00