diff options
author | Jez Ng <jezng@fb.com> | 2021-03-04 14:36:46 -0500 |
---|---|---|
committer | Jez Ng <jezng@fb.com> | 2021-03-04 14:36:46 -0500 |
commit | 8601be809e12a234bbd6264b1a1d37dba2acbe28 (patch) | |
tree | 1ace3b605ff6ea9c9dc65ab31b31801e6358728d /clang/lib/CodeGen/CoverageMappingGen.cpp | |
parent | 5d9aafc09ab5ddc4c205609e9ea4a8a9fa8186bb (diff) | |
download | llvm-8601be809e12a234bbd6264b1a1d37dba2acbe28.zip llvm-8601be809e12a234bbd6264b1a1d37dba2acbe28.tar.gz llvm-8601be809e12a234bbd6264b1a1d37dba2acbe28.tar.bz2 |
[lld-macho] Fix & fold reexport-nested-libs test into stub-link.s
The reexport-nested-libs test added in D97438 was a bit wonky.
First, it was linking against libReexportSystem.tbd which targets the
iOS simulator, and which in turn attempted to re-export the iOS
simulator's libSystem. However, due to the way `-syslibroot` works, it
was actually re-exporting the macOS libSystem.
As a result, the test was not actually able to resolve the symbols in
the desired libSystem. I'm guessing that @oontvoo was confused by this
and therefore included those symbols in libReexportSystem.tbd itself.
But this means that the test wasn't actually testing the resolution of
re-exported symbols (though it did at least verify that the re-exported
libraries could be located).
After some consideration, I figured that stub-link.s could be extended
to cover what reexport-nested-libs.s was attempting to do. The test
targets macOS, so we only have one `-syslibroot` and no chance of
confusion.
Reviewed By: #lld-macho, oontvoo
Differential Revision: https://reviews.llvm.org/D97866
Diffstat (limited to 'clang/lib/CodeGen/CoverageMappingGen.cpp')
0 files changed, 0 insertions, 0 deletions