Commit Graph

6 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 09aed384ba [lld-macho][nfc] Test that -ObjC will import bitcode with category sections
The functionality was originally added in {D95265}, but the test in that
diff only checked if `-ObjC` would cause bitcode containing ObjC class
symbols to be loaded. It neglected to test for bitcode containing
categories but no class symbols.

This diff also changes the lto-archive.ll test to use `-why_load`
instead of inspecting the output binary's symbol table. This is
motivated by the stacked diff {D99105}, which will hide irrelevant
bitcode symbols.

Reviewed By: #lld-macho, oontvoo

Differential Revision: https://reviews.llvm.org/D99215
2021-03-31 15:48:36 -04:00
Jez Ng f843bb82c0 [lld-macho] Force-loading should share code path with regular archive loads
This extends {D92539} to work even when we are loading archive
members via `-force_load`. I uncovered this issue while trying to
force-load archives containing bitcode -- we were segfaulting.

In addition to fixing the `-force_load` case, this diff also addresses
the behavior of `-ObjC` when LTO bitcode is involved -- we need to
force-load those archive members if they contain ObjC categories.

Reviewed By: #lld-macho, smeenai

Differential Revision: https://reviews.llvm.org/D95265
2021-02-03 13:43:47 -05:00
Jez Ng a817594de9 [lld-macho][nfc] Clean up tests
* Migrate most of our tests to use `split-file` instead of `echo`
* Remove individual `rm -f %t/libfoo.a` commands in favor of a top-level `rm -rf %t`
* Remove unused `Inputs/libfunction.s`

Reviewed By: #lld-macho, compnerd

Differential Revision: https://reviews.llvm.org/D93604
2020-12-21 14:44:08 -05:00
Jez Ng 78976bf3da [lld-macho] Support parsing of bitcode within archives
Also error out if we find anything other than an object or bitcode file
in the archive.

Note that we were previously inserting the symbols and sections of the
unpacked ObjFile into the containing ArchiveFile. This was actually
unnecessary -- we can just insert the ObjectFile (or BitcodeFile) into
the `inputFiles` vector. This is the approach taken by LLD-ELF.

Reviewed By: thakis

Differential Revision: https://reviews.llvm.org/D92539
2020-12-08 10:34:32 -08:00